chipKIT® Development Platform

Inspired by Arduino™

DIY Fubarino Mini in TQFP package

Created Sun, 01 Oct 2017 09:16:42 +0000 by m0wut


Sun, 01 Oct 2017 09:16:42 +0000

Hi all, I have been designing an amateur radio transceiver which has been using the Fubarino Mini as the microcontroller. Until recently, I prototyped using a commercial Fubarino Mini (TCHIP011 purchased from Farnell, v1.5) on a breadboard and it has all worked fine. I then got to the stage where I sent off some PCBs for manufacture and decided to embed the Fubarino Mini onto the PCB rather than have it as a separate plug-in module. For the circuitry around the PIC, I copied the Fubarino Mini schematic on Github ( with a few changes in that I did not connect USBID (RB5) to the USB port, but did leave in the 10k pullup, as the PIC would always be in device mode and using a scope I could find no activity on the line. I also used the TQFP package PIC32MX250F128D-50I/PT which appears to have identical pinout to the QFN part used in the Fubarino Mini. The VBus supplied from the USB was also left unconnected and the VBUS pin on the PIC, connected to the 5V rail on the PCB. This board allowed the bootloader to be flashed, the FUBARINO_MINI_USB_48MHZ ( and the Program LED began flashing but when the USB is connected to a computer (so far tested on Windows XP, Windows 10 and Raspbian) it gives "Device Descriptor Request Failed" errors.

I then decided to make a test board with no other stuff on it other than the Fubarino Mini schematic. Again, I did not connect USBID and used the TQFP part but did now connect VBUS to the VBUS pin and powered to board from the USB port as done in the Fubarino Mini. I keep trying the use the TQFP part because some members of my radio club are also interested in making the board (I'm giving them my leftover PCBs for free, I hasten to add, I'm not making any money and it is all open source and on my Github) and do not wish to solder QFN (nor do I particularly) and I figured TQFP is slightly easier, at least to inspect. I was also aware that in length matching my USB traces on my main board, I had to meander the traces more than I would like so the test board uses very short direct traces to the USB connector. This again had the same USB Device Descriptor Request Failed errors.

I am fairly happy that I am using the right bootloader as I flashed it to my commercial Fubarino Mini board and it worked fine. I have also tried downloading my software to the commercial Fubarino Mini through the Arduino IDE, copying the entire memory using a Pickit3 and loading that to the PICs on both of my boards and the program runs fine (drives the LCD and responds to button presses on my main board as expected) but the USB still does not work in the same way as before.

I did notice that the clock on the Fubarino Mini was running slightly slow (7.99975MHz according to my Rigol DS1054Z) so I tried pulling the crystal used on my boards down to the same frequency by increasing the load capacitance but this did not fix my issue. I did also try swapping the crystals between the commercial Fubarino Mini and my test board and the commercial one still worked and mine still didn't. I did notice that any crystal on the commerical board is driven between 0-3.3V and looks almost square wave, the crystals on my board are both outputting sine wave with Vmax = 2.5V and Vmin = -0.3V but not sure what is causing this.

Schematics for both boards and the layout of my test board are attached. If anybody could provide any assistance, I would be most grateful.

Many thanks, Dan M0WUT


Sun, 01 Oct 2017 11:56:54 +0000

You have your D+ and D- backwards on the USB port.


Sun, 01 Oct 2017 12:51:28 +0000

:oops: I'm so sorry, that's quite embarrassing. Apologies for wasting your time. Thanks, Dan


Sun, 01 Oct 2017 13:04:20 +0000

Hey, you didn't waste my time :P It sometimes takes a second pair of eyes to spot an error like that.


Sun, 01 Oct 2017 13:22:16 +0000

Oh, and you can ignore the USBID pin - it's disabled in the bootloader (normally) and the pin is just under normal software control as a normal GPIO port. You can just leave it disconnected like any other pin. Save yourself a resistor and the board real-estate.