Install Python 2.x and the pySerial module. Download the firmware and programmer, move the required files into a convenient directory.

Disconnect the Bus Pirate from the USB cable (and power supply if applicable). Place a jumper between the PGC and PGD pins (A), as described in the Windows quick programmer tutorial. Plug the Bus Pirate back in.

Substitute <hexfile> with the name of the firmware .HEX file, something like v25-Firmware-v2.hex for the Bus Pirate v2go. Replace <serial port> with the device name you system assigned to the Bus Pirate’s FTDI USB->serial converter chip.

Linux: /dev/ttyUSBx (/dev/ttyUSB0) or /dev/ttySx (/dev/ttyS1)

OSX(?): /dev/cu.KeySerialx (/dev/cu.KeySerial1)

Windows: COMx (COM3)

The serial port name can be tricky, hopefully these examples help. Replace ‘x’ with the number for your system. Look in the system dmesg to find the Bus Pirate on Linux, or in the control panel on Windows.

Ignore any verify errors at the beginning (0x0, 0x1) and between 0x400 and 0xbff, these are bootloader protected locations. A really nice thing about the Python programmer is that it knows to ignore errors in the protected bootloader section.

I often use the the python updater and always get some errors outside the protected range. However the BP seems to run all right so I ignore them. Jason – if BP runs after flashing don’t worry about the errors.

I wonder what the difference is in error reporting between the versions? I’m guessing that the python version is more verbose and isn’t ignoring one errors that Microchip’s updater doesn’t report. There could also be a minor error in the Python updater, but as you noted nobody has ever has ‘problems’*.

I do have exactly the same error as Jason, but I’m using the microchip windows client. All the extra errors appears after 0xA800 (like jason). It looks like the pages are writeprotected like the bootloader (i.e. cannot erased, but written once??) Unlike what is suggested the errors are serious (weird text and such) and should never be ignored in my opinion!! flashing/clearing multiple times didn’t help and the error remains the same.

I got an BP from the preorder 2 from seeedstudio. More people with the same problem?

the option to preserve the fuses prevent the memory area (a800 and up) to be erased and thus written properly (the verify errors). disabling this option solves this. All the compiles I’ve done so far (as described in the how-to-compile wiki entry) include the fuses so it should be ok (stress on should ;)) I just tested it and it did work (no indept testing so far)

@Chris – thanks for the confirmation, we’ve been discussing this in the forum. Did you load one of the translations? They’re the only version that should reach past 0xa800. I try to verify each before release.

I’ll do some testing with erasing the configuration bits, I worry that a chip without config bits won’t have the wherewithal to get loaded again. How is the chip supposed to know what clock source to use with the bootloader if the config bits are erased? There may be some mechanism to address this, but I’d like to know for sure before recommending that everyone do it.

I can use it without a problem, but there is no way to update bootloader or anything.
I’ve used P24qp of v2tov41-bootloader-update-va3 package with all versions of python that are avalaible on Debian (2.1, 2.2, 2.3, 2.4, 2.5), and always got this:

Hopefully, you’ve long since solved your problem, but if not…I just went through upgrading my Seeed BPv3 from FW “v2.4-Seeed” to “Firmware v5.10 (r559) Bootloader v4.1″ . Maybe the details will be helpful for you.

The key piece for me was manually setting the serial port speed to 115k. Before running the bootloader upgrader.

This failed with something about Device=ffffff not recognized. What this really was about, was that the bootloader upgrader was opening the serial port at 9600 instead of 115200. Manually set the speed to 115k and check in the next two steps…

I did not open the terminal indeed… and so missed a crucial step. So that explains that the bootloader was still 1.2.
I now tried to upload the upgrade BPv3-v2blupdaterVa3-v4.1.hex firmware again but that only gives as many verification errors as there are bytes in the file.. So my guess is the BP is dead now? (Wrong config word?)

No terminal either. But i can still use P24qp to ‘info’ the bootloader: v1.2

Is there still a procedure i can use to fix the BP or do i need a 3.3v programmer? (Only got a 5v programmer)

I’m not really sure, the updater contains the config bits and you should be able to bootload it as much as you want without problem. Did you try to upload the actual v4 firmware with the .py uploader as well? That will do it every time :(

I’m not sure about the programmer. SparkFun shipped a bunch with 5volt regulators instead of 3v3 regulators, and they worked fine (for a while…). You might be able to get away with programming the PIC at 5volts if the programmer supports the 24fj64ga002.

Yes i did try to upload the v4 firmware. (Because i thought the bootloader upgrade worked)
After that i was able to connect to the BP once and it said “Firmware version 4.1, bootloader 255.255″ Next powerup it was gone.

I think the v4 fw try screwed the config word indeed and it now runs with the wrong clock in mind. Ill try to flash it with the 5v programmer…

Does the v4 firmware contain everything? config+firmware+bootloader? I mean if i get that hex in, is the procedure then completed? Or should i just try to set the config word only and then install the bootloader again? (since 1.2 is obviously still in there..)
And what is the config word then?

I downloaded the laters (4.2) bootloader hex into the BP with a pic programmer, used the bootloader to install the firmware. Everything is working fine again! (needed a programmer though, so for anybody else: DO NOT USE P24qp.py TO PROGRAM v4 firm, NEVER. Only the bootloader-upgrader. As stated above..)

***STOP*** DO NOT UPLOAD A V4 FIRMWARE TO A V2 BOOTLOADER WITH P24QP.PY!!! The Python utility erases the entire chip, including the ‘configuration words’ that determine how the pic behaves on start-up. The v4 firmware does not contain replacement configuration words, so the Bus Pirate won’t start from the correct clock after programming a v4 firmware to a v2 bootloader with p24qp.py. Only Upload v2 firmware or BPv3-v2blupdaterVa3-v4.1.hex with P24QP.PY.

I LOST MY BUS PIRATE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1

***STOP*** DO NOT UPLOAD A V4 FIRMWARE TO A V2 BOOTLOADER WITH P24QP.PY!!! The Python utility erases the entire chip, including the ‘configuration words’ that determine how the pic behaves on start-up. The v4 firmware does not contain replacement configuration words, so the Bus Pirate won’t start from the correct clock after programming a v4 firmware to a v2 bootloader with p24qp.py. Only Upload v2 firmware or BPv3-v2blupdaterVa3-v4.1.hex with P24QP.PY.

I LOST MY BUS PIRATE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1