Bootloader v4 (ds30 Loader)

[ian]

Ok, that was easy. Here's the ds30 loader and compatible bus pirate firmware for BPv3 (ONLY!!! not for v2go!!!!):
http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/firmware/v3-nightly/BPv3/ds30Loader

Don't use it unless you have a programmer to undo it, this is not final at all!!!!!!

To upgrade bootloaders:
1. Upload ds30Loader-v00.hex with the existing bootloader.
2. Remove the jumper and reset the PIC
3. Download buspirate.hex with the ds 30 loader GUI.

Notes:
It currently uses timeout and not jumper, this needs to be fixed.
Programs in under 10 seconds with no error messages!
Corrects problem on some PICs that can't upgrade at 115200bps.
No MODE LED indicator yet.
Needs different Bus Pirate firmware compile.
Need to examine the memory location to make sure we're getting the most out of the pic, it seems to be located at the second-to-last page. Why??

Here's the source:
http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/ds30Loader

[Sjaak]

Cool!!! you are very fast! I just arived home after work.

Is it perhaps better to move de loader to the same location (to assure backward compatibility and no different compile settings) as the old one? The only change (besides the start block)  is it should program the fuses after an erase of the last block and protect the first block.

I'll look into the source, perhaps some helpfull things in there to overcome more wasted space ;)

[ian]

I would really appreciate your looking at the source. Maybe the bootloader can be in the last page and we can not reporgram config words ever (or just config words with special effort?).

It can't be at the same place because then there's no code to complete the initial bootloading. It's only possible with 2 steps I think.

[alexdresko]

Holy cow. I'm not really sure how we got from the original problem to this, but your conversation has been very entertaining thus far. I've been writing software for Windows both professionally and as a hobby for 13 years now, but this stuff is like Chinese to me!  Keep up the awesome work, fellas! I really wish I could help more, but I'm just now getting started with the hardware stuff.

[Sjaak]

It looks like a fairly complete bootloader to me :D

However (;)) I noticed the following:

- no protection of the fuses
- no protection of the bootloader itself
- in case of a failure (transmissiontimout) it jumps to the user code but it is uncertain if this is valid code or the jumptable (usrapp) is correct. I would prefer to restart the loader (bra __reset).

The first two things can be solved in the client by sanity checking the input. (or keep on reading ;))

If the bootloader is smaller then flashblocksize - configfuses then I would place it in the last block. Then the fuses are protected. An disadvantage is that the reset vector/isr vectors are in the first block and no protection for those.

After compiling i got the bootloader from A400 - A4FF . If I understand correctly it is 256 programwords (3 bytes/word?). the pagesize (the smallest possible chunk which can be erased is 1024 programwords? If this is true it can be fitted in the last page, together with the fuses. It will also leave space for some little checks (protecting the last page/fuses and assure the reset vector points to the bootloader). It will leave approx 0xA800 words for the buspirate program (minus some vectors)

I think the reason to place it in the second last page is to allow programming the fuses without wiping the bootloader itself. To set a fuse you need to clear the page (every bit to 1), but the program runs from there. After an erase it encounters only nops and eventually hangs (reset vector point to bootloader and keep executing nop, reset etc)

[Sjaak]

Hmm I just checked the homepage (overlooked it somehow :S ). It appears the clientside of the tool does the sanity checks. So I think that will be OK. However I think it is better to incorperate the checks in the bootloader, but my asm skills suck very big time....

There is BTW a newer version, and i dunno what the impact will be..

[ian]

@alexdresko - Funny you should mention :) I could use some PC side help on this (and several other) Bus Pirate projects. Keep reading ;)

@Sjaak - I don't know any ASM either, not a drop. I'm feeling my way in the dark, but it's all pretty straight forward.

I actually sat down and read the memory section of the datasheet last night, now I feel like an expert (or more confused than ever). (EDIT: it was more confused than ever, not expert :p). Actually the smallest  erase block is 512 (0x200) words (1592bytes, FTIW). The bootloader is supposed to go in the next-to-last block. The 64ga002 has 0xac00 words of memory, so it should be located at 0xa800. Instead, it's located at 0xa400. I was wrong about this. Each address counter unit is 2, so a full page is 0x400 (1024) ACU, not 0x200 (512) like I had assumed. Looking at line 142 of de30Loader.s, there's this:

      .equ   STARTADDR,   ( FLASHSIZE - 2 * (PAGESIZE * 2) )       /*place bootloader in 2nd last program page*/

That clearly locates it 4 pages from the end. It's actually the next-to-last page with the ACU conversion.  We still need to change it to save to the last page though:

      .equ   STARTADDR,   ( FLASHSIZE - (2*(PAGESIZE * 1)) )       /*place bootloader in last program page*/

I believe the strategy is to place BL one page from the end so the config bits page is still erasable. I never plan to renew the config bits, so this shouldn't be a problem. The ds30loader doesn't do config bits except in advanced mode (not sure of this).

Now, here's the problem: since the software does all the sanity checks (the firmware does have a CRC check to prevent accidental runaway programming on an error), it also has this fourthsecond-page-from-the-end location hard-coded. In advanced mode you can check a box that allows overwriting of the bootloader, in our case it wouldn't be the actual bootloader, just this blank memory space. It would be great if we could enter the bootloader location in the ds30loader configuration .xml.

I got the newer version, I'll start working with that, but it does have the same problem. I've been in contact with the author, so I'm going to write him now and see what his thoughts are on the matter. Maybe I'm missing something really simple.

[ian]

There's updated source and compiles for the ds30loader in the SVN. I added bootloader jumper detection, and I used a new method that will work for both v2go and v3. v2go and v3 can use the same bootloader now! Yeah! THIS IS STILL NOT FINAL AND IS FULL OF BUGS!!!! PLEASE DON'T USE THIS IF YOU DON'T HAVE AN ICSP TO REVERT TO THE OLD BOOTLOADER!!!

There is still the issue of location, however. The bootloader is located in the fourth-to-last page of program memory. I'd like it to be in the last (could live with next-to-last). Changing the location in the firmware is no problem, unfortunately the fourth-to-last location is also hard-coded into the PC upgrade applications. This creates two problems. First, the upgrade app protects the wrong page and allows erase/writes to new bootloader location. Second, the post-bootloader jump instruction get written to the wrong location. The upgrade app writes a goto instruction right before the bootloader so the bootloader knows where to find the actual firmware, it currently writes to the final instruction of the fifth-to-last page, but we'd need to move it to the next-to-last page.

The ideal solution would be to extend the configuration file of the ds30Loader to accept a few optional parameters. First, the starting page (or starting instruction) and length of the  bootloader. This way we can locate it where ever we want. Second, a setting to configure where it relocates the goto jump instruction. Finally, the option enable/disable burning of the configuration fuses so we have extra protection if the bootloader is in the last page. The relevant code is located here:
http://code.google.com/p/the-bus-pirate/source/browse/trunk/ds30Loader/loader-apps/ds30%20Loader/1.2.3/ds30%20Loader/clsHEX24FJ.cs#220

----------------------

I also figured out the flash config words from the datasheet. They're copied to the correct registers at startup, then you are free to reflash them. The new config takes effect on reset. That's why the existing bootloader worked for you without 'preserve flash configuration bits' checked. The only trouble comes if the update can't complete, or looses power before the new config words are flashed, then the chip is bricked until the config bits are reset with an ICSP programmer. That's 100% certainty of brickage, not just a minor chance.

What I really don't understand about the existing bootloader, is why it only erases to 0xa400 or 0xa600 if it's only trying to protect the last page (0xaa00+)? Maybe the protocol only supports multiple page erases? I don't want to fix it because it's not explicitly GPL licensed. I'd rather upgrade to the ds30loader. I was wrong about this. Each address counter unit is 2, so a full page is 0x400 (1024) ACU, not 0x200 (512) like I had assumed. The current bootloader erases to 0xa800, which is the last page with the config words.

[Sjaak]

wow! Nothing to do today? :P

Let me see if i come home easily today because of the snow here... I can make a small .hex to program the fuses first, this will make it a bit more safe ;)

Perhaps i could also make a script to use the new loader, the protocol is very easy.

[alexdresko]

Somehow I missed where my involvement could potentially come into play?

[ian]

@alexdresko - We need a C# programmer (free Visual Studio express) to make a few minor changes to the ds30 Loader address calculations. I put a bounty on it, longer description here:
http://dangerousprototypes.com/2010/01/05/bus-pirate-bootloader-v3-testers-help-needed/

I installed the IDE and got the GUI to compile, but I don't have any more time tonight to make the changes. I've never used C#, but the changes are so minor it doesn't seem to matter.

If that's not your thing, we still need a windows compile of USBPICPROG that outputs through a serial port to bring PIC programming support to the Bus Pirate. Sean already submitted a patch, but there were some errors with the windows compile:
http://dangerousprototypes.com/2009/12/10/bus-pirate-pic-programmer-update/

Finally, we need to adapt the USBPROG support in OpenOCD to push data through a serial port to bring JTAG debugging to the Bus Pirate:
http://dangerousprototypes.com/2010/01/01/bus-pirate-openocd-jtag-support-update/
http://dangerousprototypes.com/2010/01/04/bus-pirate-openocd-jtag-firmware-port-v00/

If you're ever interested in working on any of these items, I believe they all have some sort of bounty attached. I'm mostly a microcontroller guy, the dependencies involved in compiling for a desktop scares me so I try to stay away from it :) I try to bribe people to do it for me whenever possible.

[alexdresko]

C# (and .NET in general) is my specialty. I'll happily take a look at it.

[alexdresko]

@ian: The latest ds30 code in SVN does not compile due to a handful of missing class files. My guess is something isn't checked in right. Can you manually zip up the entire trunk or the highest level ds30Loader directory and attach it here?

[ian]

I just used the source from the latest download. To compile the GUI, I had to add the dsloader project manually from it's folder, then add the Ghelper.dd and ds30loader.dll to both projects. I hope that makes sense, I'm not well versed in the vocabulary of C# and visual studio.

[alexdresko]

@ian: Ahhhh.. ghelper.dll was the missing link. When I'm done with this, I'll make sure everything just works when you get latest. I'm also the "build master" at work so making sure things compile easily for everyone is second nature.