See the latest version in the documentation wiki.
The solution was to decrease the speed of the quick programmer utility to the Microchip recommended default, 9600bps. Unfortunately, it takes nearly 3.5minutes to update the firmware at 9600bps.
Most PICs, perhaps all, will work at higher speeds. Right click on the quick programmer speed setting for an options menu. Try connecting at different speeds until you find the highest reliable speed that works with your chip.
Read on for a detailed post-game analysis of the error, where it came from, the issues we faced, and the solution we ultimately chose.
The Bus Pirate project used Microchip’s PIC24F bootloader example. The default speed of the Windows programmer utility is 9600bps, it takes about 3.5 minutes to upload a new firmware. The bootloader firmware on the PIC uses auto-baud to determine the UART speed, the quick programmer sends 0x55 and the PIC UART calculates the baud rate. We increased the quick programmer speed setting to 115200bps and the PIC bootloader detected the correct speed and worked fine.
In many PICs (all of ours and 350/400 of preorder 1) this worked fine, but some PIC crystals are worse and the UART is out of specification at 115200bps. The problem was only evident because so many were made at once, we only caught it because of Seeed Studio’s excellent quality control and testing. Thank you Seeed!
The technically ‘correct’ solution is to use the high-resolution baud rate generator in the PIC (BRGH=1), then all PICs will work at 115200bps. We used this setting in the code for the Bus Pirate terminal, that’s why the terminal worked and the bootloader didn’t.
Unfortunately, PIC24FJ64GA002 REV #3003 (B3) has a problem with auto-baud when BRGH=1. There is a work-around in errata but it didn’t work consistently enough for production.
That left two options:
1. Make a new bootloader firmware that ignores the auto-baud byte and works at a fixed 115200bps/BRGH=1.
2. Reduce the speed of the upgrade utility back to the Microchip default.
The best solution was #2. It’s risky to introduce a largely untested firmware in the middle of production. Making it worse, a recently upgraded PIC C compiler introduced even more certainty. Also, it saved Seeed the effort of re-programming and testing 50 Bus Pirates.
The consequence is that bootloading is much slower, however, it is a rare operation so most people won’t be too inconvenienced. You can also test your PIC at higher speeds. I haven’t yet received a test case for analysis, but I hope all PICs work to at least 57600bps.
Having two versions of the bootloader in the wild would have been a support nightmare, there would have been no way to tell the difference between bootloaders without an ICSP programmer. Think about all the router and game console hacks that have extensive instructions for determining if you have the ‘right’ version of the hardware. PCB markings, chip date codes, etc, and even that’s no guarantee. Now we know exactly how manufacturers get into this situation.