Linux - Bootloader-Programmer

[JoseJX]

Thank you very much for the dumps! These really help. I have been picking at the source code to figure out what's going on, but having the exact values written to the device always makes things a bit clearer.

As far as I can tell, the "go" command should actually be two commands, a packet with 0x08 as the command (third byte), followed by the packet with 0's (which is the reset command). The reason why it wasn't working for me previously is that since the writing wasn't working properly, the bootloader timeout value wasn't being written. Because of this, when the finalize command was written, it was copying 0xFF to the timeout value then resetting back into the bootloader. Oops!

I'll take a look at the dumps tonight to figure out what I'm missing with the write command. I also noticed that it appears that the Microchip application writes values into the configuration words which isn't mentioned in the app notes, which may be related to the remaining issues with my app.

[JoseJX]

Some progress, but I haven't fixed everything yet! :)

The reads during errors are gone now, I believe that the read function works properly now, which is good! I was wondering though, what are the configuration words set to by default?

In my dump I made before upgrading the firmware to bootloader v2, I have:

DFF9FF00
7F3FFF00

Are these right? Also, I'm a little confused as to what the actual length of the memory is. With the PICKit2, reading out the entire flash results in addresses 0x000000 - 0x0157FF being read out. The flash files you provided also either pad to 0x0157FF or define data for those addresses. However, it appears that the windows configuration you provide only specifies 0x00ABFF as the upper memory address and doesn't appear to write any further (if I'm reading the code correctly). A size of 0x00ABFF would match with the datasheet better as well! To top it off, reading from addresses above this range using the application seems to cause it to error out... hence the confusion!

Thanks for the help. Once I get my version working, (which I've been updating as we go) I'll send patches for specific functionality so we can get the version in your SVN working as well. :)

[JoseJX]

Okay, never mind the last bit (although I'd still like to see the configuration registers to make sure I've got it right). I missed the part in the bootloader where each address addresses two bytes, not a single byte. This discrepancy is what was screwing up all of my address calculations and read/write functions. When I get out of work, I'll fix up the issues and hopefully we'll have a working Linux programmer. :)

[ian]

Config words appear to be correct, save some endianness (from MPLAB):
@ABFC = F9DF
@ABFE = 3F7F

I also started a new topic to discuss the hardware I2C mode you PMed me about. There's already code for it, but I was never able to test it because I only had REV3 silicone.

[JoseJX]

Success! The programmer at http://dev.gentoo.org/~josejx/bp_prog works for me! I've only tested with the v2 firmware, but it should work for others as well.

The programmer uses the same configuration file as the one used for the windows programmer. There are probably still bugs and rough edges, but I successfully used this program to read, erase, flash and restart my BP from Linux. It should also work in OSX and Windows, but I haven't tested it.

The next step is to break up the code and give it to you as patches against the work already done.

[ian]

Congratulations, great work!

However you want to do it is fine. We can always host a second Python programmer if that's easier.

[JoseJX]

It's entirely up to you and Peter, whatever you think is better for the project. :)

If someone wants to use my programmer, the steps for doing so are actually pretty simple:

• Attach the jumper and plug in the BusPirate
• Run bp_prog -a <hexfile> -s <serial port> -v with the configuration file (P24qp.ini) in the same directory
• Remove the jumper before the writing is complete

The "automatic" mode will erase then program using the specified file. You will most likely have to provide a serial port path since the .ini file indicates a port #, not a device. I'd also recommend using the -v command to verify the written rows to help ensure that the device was written correctly.

[ian]

If you add an open source license to the source, I'll copy it to the SVN.

Can you please copy and past your terminal output as a usage example? I'll put a link on the project page.

[ian]

I tried the programmer successfully with the Windows version of Python 2.x.

You ignore the bootloader area, what a nice touch, the Microchip programmer doesn't have this option.

The first two bytes gave an error, but I assume this is because the bootloader modifies the start address.

I also got verify failures at c04, c05, c06, a8f8, a8f9, a8fa, a8fc, a8fd, and a8fe.

Firmware seemed to work OK. I didn't remove the jumper, is this a problem? It went into the firmware just fine with the jumper attached. I can tweak the bootloader or firmware if this is causing an issue.

The update seems a bit slow. I used 115200bps, which works fine on my PIC, and it seemed to take longer than normal. There was much less frequent traffic, the TX LED was only on intermittently, instead of constantly as with the Microchip programmer utility.

I'm writing a guide for the Python programmer now. Is your serial port on Linux specified as /dev/ttySx? Do you know what it should look like for a Mac?

Can we change the name to P24qp.py to be consistent with the existing programmer?

[JoseJX]

Glad to hear that it works on Windows too! On linux, at least with a modern kernel and a default udev configuration, it should show up as /dev/ttyUSB0 (assuming no other USB serial devices). 

One easy way to find the device is to look in the system dmesg for a line like:

usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0

As for OSX, I *think* it'll show up as /dev/cu.KeySerial1

The first two bytes will give an error because that's where the bootloader updates the address to jump to (either the bootloader code or the user mode code) afaik. I could tell it to ignore this location too if you want. I'm not sure why the other areas were not verifying properly, it does seem to work fine here. I'm not sure why the speed is lower, but since it does seem to work, I'm not too worried about it. :)

As for removing the jumper, you're right, it appears this isn't needed. I was concerned that it would start back up in bootloader mode again after the reset but this isn't the case. I've removed the warning.

I have renamed the file to P24qp.py and added a COPYING file, along with a GPL header. Hope that's okay. The latest version is located at http://dev.gentoo.org/~josejx/bus_pirate

[ian]

I uploaded the source:
http://code.google.com/p/the-bus-pirate/source/detail?r=176

and corrected the file name in the help text:
http://code.google.com/p/the-bus-pirate/source/detail?r=177

[ian]

When the PIC exits the bootloader it doesn't reset, it just jumps to the modified firmware start address. That's why you don't need to remove the jumper.

[ian]

I wrote a guide for the Python programmer:

http://dangerousprototypes.com/2009/08/06/bus-pirate-firmware-upgrades-on-linux-osx/