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 ... ds30Loader (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 ... ds30Loader (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/ds30Loader)
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 ;)
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.
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.
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)
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..
@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. [s:]The 64ga002 has 0xac00 words of memory, so it should be located at 0xa800. Instead, it's located at 0xa400.[/s:] 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*/
[s:]That clearly locates it 4 pages from the end.[/s:] 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 [s:]fourth[/s:]second-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.
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 ... 4FJ.cs#220 (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.
[s:]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.[/s:] 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.
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.
Somehow I missed where my involvement could potentially come into play?
@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/ ... lp-needed/ (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/ ... er-update/ (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/ ... rt-update/ (http://dangerousprototypes.com/2010/01/01/bus-pirate-openocd-jtag-support-update/)
http://dangerousprototypes.com/2010/01/ ... -port-v00/ (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.
C# (and .NET in general) is my specialty. I'll happily take a look at it.
@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?
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.
@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.
As promised I made the hex file which only programs the fuses.
:020000040001F9
:0857F800DFF900007F3F000013
If you add this (derived from setfuses.hex) to the very first lines of the intermediate firmware (the upgrade so to speak) it will assure that the fuses programmed first. Then we can let people burn it with the old program, without too much risk :) better to also advise using a laptop (less prone to power outage to be almost really sure :P)
so the upgrade procedure will be:
- start P24QP program (or script)
- connect to device
- load intermediate firmware
- clear device
- write device (ignore verify errors from 0x400 -0xbff) *)
- do the C30 steps (couldn't try it because of no programmer ;))
*) could be avoided when the appropriate line are delete from the hex
Shouldn't you check if pin goes down and then for up in the modified? to rule out the possibility of a bad board/solder/pin?
add this between 226 een 227
bset LATB, #RB0
btss PORTB,#RB1
bra quit
perhaps repeat it 10 times like the old loader?
repeatchk:
bset LATB, #RB0
btss PORTB,#RB1
bra quit
bclr LATB, #RB0
btsc PORTB,#RB1
bra quit
dec WCNT, WCNT
bra nz, repeatchk
All my asm comes with _no_ warranty whatsoever !!
@sjaak - thanks for the ASM. I think the extra check is a good idea. The current bootloader twiddles one pin up and down 20 times, while watching with the other. If it matches 20 times, then the bootloader activates. The new method uses the internal pullup resistor to hold the input pin high and grounds the other pin. If the input pin is still high, there is no jumper, if the input pin is low there is a jumper. I think this is a better solution because then v2go and v3 can have the same bootloader. V3 and v2go have a different arrangement of programming pins, so the bootloaders are different to avoid grounding the check pin when the jumper is moved over one space for storage/normal operation.
In other news, I was wrong about the incorrect placement in the PIC memory. The placement is correct. The ds30 Loader author explained to me that each address counter unit is 2 bytes, so the pages are on 0x400 boundaries in the program view, not 0x200:
You should have faith in my code ;) Address is kind of byte oriented,
1 word = 2 pcu (program counter unit) = 3 bytes.
1 page = 512 words = 1024 pcu (0x400) = 1536 bytes
So the last page starts at 0xA800, the second last page starts at 0xA400
What you have done now is to place the bootloader in the middle of the last
page.
It still doesn't eliminate the need to change the bootloader application. To get the most out of the PIC24FJ64GA002, we should put the bootloader in the last page with the config words. This nets us about 6K extra program space, eliminates the erase error of the current bootloader, and no more verify errors at all.
I successfully compiled the bootloader app in C#, I'll try to hard code these changes for use with a test firmware and bootloader. We can add a more flexible configuration method later, but the ds30 Loader author is also planning to add this feature to the app eventually:
I was actually thinking of adding two text boxes in advanced tab in the GUI
for the user to choose custom bootloader size and placement. But the next
release may take a few weeks so for now you're better of hardcoding what
you want.
Ok,
so what is the current state here?
do you have a new bootloader that you want me to load then use to load a firmware? as i have the v2go and the v3 and a pickit2 im happy to play with versions if you like.
@scorpia - thanks! At the moment, I'm updating the PC application to cooperate with the new bootloader location. When I get it going, it would be great to have you test upgrades on both platforms. I'll post an update here soon. It all actually going much better than expected :)
Cool! you are making lots of progress in short amount of time. You also learned a bit of C#!! :P
Did you contact the author also about moving some checks into the loader (there is plenty space for that)?
- don't allow to erase the running bootloader (dunno if the program can read the program counter?)
- after clearing the first page write immediate a jump to bootloader
- after an timeout/communication error the user program is tried to run ( a jump to twee words before the loader which is a goto to the user app). This is ok when the jump at 0x0000 is to the bootloader (after a reset the bl is run again and programming can be resumed/retried) Can be solved by adding a command for exit. Need also some tweaking of the client.
I think I can whip up some asm to do the second and third part tonight.
@sjaak - It is up to us to make any changes to the bootloader firmware. The author doesn't want to add bootloader protection, but mentioned that others had so it's possible. There is a ton of extra room for that stuff. If you'd like to work on it, I can give you SVN access.
The author is going to add the ability to position the bootloader according to configuration values, so we can use my hard-coded version for now, and then use the latest ds30Loader when available.
The final firmware, bootloader, and loader app are all in the SVN now under v4-nightly. My next post will explain how to use it.
let me first try to come up with some assembly :P
Here are the test files for the bootloader. I've tested this extensively, and it uses the correct memory locations, so it should be 'final', save any extra protections we add to the bootloader.
This is still not done, so please don't do this unless you can revert to the old bootloader (or upgrade to the final version) with a PIC programmer. You've been warned!
Overview:
What we're going to do is load the new bootloader with the existing bootloader, then erase the old bootloader by uploading the main Bus Pirate firmware.
Notes:
The new bootloader requires a different version of the firmware than the old bootloader, they are not compatible. Bus Pirate v2go and v3 now share the same bootloader and firmware. You must use this custom compile of the ds30 Loader GUI application because we use memory locations different than the defaults.
Because this involves erasing the last page of the firmware, there is a dangerous period between erasing the chip (green X button) and the end of programming. If you lose power, or fail to complete the upgrade, there is 100% certainty that your Bus Pirate will be bricked. It might be best to use a fully charged laptop connected to a power supply just in case, though I've never had a problem.
You will need to install the loader app found in v4-nightly.zip, I'll work on getting a simple executable and script put together soon.
Procedure:
1. Put at jumper between the PGC and PGD pins, as for a normal upgrade.
2. Plug in the Bus Pirate, the MODE LED should light.
3. Connect with the PIC24 Quick Programmer utility.
4. IMPORTANT: uncheck 'Preserve Flash Configuration Words on Erase'.
5. Open the 'v3-Bootloader-v4.hex' firmware file for v2go/v3 (v1a will eventually be supported as well)
6. Erase the chip with the green 'x' button. Proceed quickly and with caution, the configuration words are now erased and any loss of power will brick the Bus Pirate.
7. Press the program button (down arrow).
8. When programming is complete, press the green play button. The dangerous part is now over.
9. Remove the jumper and unplug the Bus Pirate.
10. Plug the Bus Pirate back in. The MODE LED should be off.
11. Place a jumper on the PGC and PGD pins, the MODE LED should light.
12. Start the ds30 Loader GUI. Configure it as shown in the image attached to this post.
13. Load the 'v3-Firmware-v4.hex' from the v4-nightly.zip archive.
14. Press the download button.
15. When bootloading is complete, remove the jumper, unplug the Bus Pirate, and plug it back it. The upgrade is complete and you should see the terminal prompt.
The archive was too big to attach, you can get it here:
http://www.whereisian.com/files/v4-nightly.zip (http://www.whereisian.com/files/v4-nightly.zip)
or here:
http://code.google.com/p/the-bus-pirate ... v4-nightly (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/firmware/v4-nightly)
Ian,
Did you try to include that line in the test hex?
:020000040001F9
:0857F800DFF900007F3F000013
this should write just the config bits (at least that is wat the hex suppose to do, I dunno if the bootloader/P24QN program does some translating, but it appears that it just sends the .hex over) Aft
you can do that with in a cmd shell:
copy fuses.hex + newbootloader.hex final.hex
alternatively you could strip the empty lines to speed things up (less time to let things go wrong) Should be no problem according to the intelhex standard.
Stripping the empty lines from the 'upgrade' bootloader is probably a good idea, many people are upgrading at 9600bps and it takes 3.5minutes. The last two pages should be left because the jump instruction is in the two instructions prior to the bootloader at 0xa800. May the programmer is smart enough to write a partial page (we should test)?
The bootloader goes in the same page as the config bits, and we can erase at minimum a single whole page. The upgrade also includes the config bits.
Haha, I just tried it in reverse and it works! You can reload this modified version of the old bootloader with the new bootloader, remove the jumper and reset. Connect with the P24 quick programmer, then erase the chip with preserve flash config words unchecked, then upload the old firmware. Tada! Back to the old bootloader!
I just got a nice message from the author of ds30 Loader, he's already added support for us:
Programming is so fun that I couldn't wait to implement the features you want.
Here's a new gui with custom bl placement. Test it and let me know.
I've successfully tested it on dsPIC30F.
In summary, there's nothing I need to do with the ds loader then, right?
I stripped the firmware (attached) for installing the new bootloader a bit.. the filesize came down from 242kb to 4711bytes. When uploaded at 9600baud it should take a mere 5 sec (4.9 to be precise :P) I dunno if you need the interruptvectors (i don't see any reason) then it can be further trimmed down to approx half (also attached).. If the last one does work it only takes less then 2 sec...!
Could you give it a try? :D
Another option is write a small program that first erases the last flash block, write the fuse, write the new bootloader, erase the first page, write the reset vector, write interruptvectors (if necessary) then jump to new bootloader (or reset). This option will be as safe as it can gets, especially powered from a laptop.
@alex - It looks like it, I'm really surprised this came together so fast!
@Sjaak - I tested the stripped-naked because I don't see any need for the interrupt vectors. It didn't work (yet), but I read out the chip after the upgrade and most stuff seems to be OK. The jump instruction is in the wrong place though (0xa780), but that should be easy to fix. I attached the dump to this message, but I haven't really dug into it yet.
Here's the text file the P24QP utility made from the naked hex after loading it (you can do this too without actually programming). It looks like it ignored the actual address you put for the first jump instruction, and put it at the beginning of the other data instead.
This is the important bit:
014F00 00 A8 04 00 00 00 00 00 2A A9 00 00 2A A9 00 00
014F10 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014F20 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014F30 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014F40 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014F50 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014F60 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014F70 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014F80 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014F90 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014FA0 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014FB0 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014FC0 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014FD0 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014FE0 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
014FF0 FF FF FF 00 FF FF FF 00 00 00 FF 00 00 00 FF 00
015000 2F 8C 20 00 42 27 A9 00 45 07 A9 00 42 A7 AE 00
015010 FE FF 37 00 F0 FF 2F 00 60 19 88 00 CC 22 A9 00
015020 C8 22 A8 00 68 A0 A8 00 CC 02 A9 00 C8 02 A9 00
015030 00 00 00 00 00 00 00 00 CA 22 AF 00 7C 00 37 00
I think it's trying to align the data on page boundaries. Maybe with a few rows of extra padding. I'll try the one with the interrupt vectors, that provides a page of padding.
Really strange, with the stripped .hex it works, but only if I bootload it twice (and then only after the initial run). I dumped the memory, and the jump instruction to 0xa800 that should be at 0xc00 is 0x0000. Maybe it needs the range between oxc00 and 0xfff to force it to program the jump instruction. I'll test this now.
Hmm really strange. Isn't it something the bootloader does (the jumping)? Gets that page erased (0xC00)?
Perhaps better idea to make an 'installer' ;) I did look into it yesterday night and it shouldn't be hard to write. I'll look into it tonight.
I think it's something the quick programmer is doing. It relocates the jump instruction in the user firmware (located at 0x0000) to 0xc00 when it programs the chip. Since the 0xc00 page isn't there, I think the quick programmer never programs it to the new location. I think a good test is to add that page (all blank) and see if it works better.
I'm trying to add the extra section for a test, but how do you calculate the :020000040001F9 you used? Is it just the first is :020000040000, second is :020000040001, third is :020000040002? (each plus checksum?)
Never mind, I found it on wikipedia. This method didn't work for me.
I like the idea of a quick flash, but I'm also OK with the current method. I've never had any problems doing it, but it is certainly possible. If the PIC doesn't have anything in the upper page, it would even be possible to do the upgrade without erasing the config bits. It's possible to check by reading out the chip with the quick programmer (up arrow button).
The new version of ds 30 loader works, but it still has some minor UI bugs. I've also asked the author if a 'distribution' mode is possible with all settings configured correctly according to a .xml file for dead-simple end user upgrades. We'll be ready to deploy soon.
Before we're done, though, I'd like to add any extra checks to the firmware part. Do you still think it needs to check the state of the jumper more than once? I've been using it for a few days now and I've never had accidental entry (or non-entry).
I think it might be good to protect the bootloader from erasing. I'd need to figure out how the address is transferred, store it and compare it to each line #, and skip writes/erases to the upper page (or a page range for more flexibility). It is currently possible to ruin the bootloader with the correct (incorrect) settings in ds30 loader. That's really going to stretch the limits of my ASM :)
Great!
Extra check don't hurt I guess, better safe then sorry. (Or write a good disclaimer!!). Also there is plenty of room.
The adresscheck could be around row 379 for erase and for writes around row 392.
Here's a dump of the protocol:
Length 198: 00 08 80 02 C1 00 61 74 00 20 73 00 65 74 00 0D 0A 00 00 20 00
Length 198: 00 97 80 02 C1 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Length 198: 00 98 80 02 C1 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Length 198: 00 9A 00 02 C1 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Looks like:
|TBLPG|upper address|lower address|command(write, erase)|data length|data|CRC
Each TBLPG addresses 32K words, this pic only has 22Kwords, so we probably don't need to worry about the TBLPG address.
For this chip, and this bootloader location, we probably only need to check that the write address (WADDR) + data words (WCNT/3) < bootloader start word.
The packets appear to consistently be one row (C1=193, subtract the CRC = 192, 192/3bytes per word=64 words).
I added this to the ds30loader.s, it still needs to be ASM-ized:
;----------------------------------------------------------------------
; Check address
;----------------------------------------------------------------------
;check that address does not overlap bootloader
;if(TBLPAG=0){
; if( (WADDR+(WCNT/3))> (#PGMENDWRD) )
;bra Main ;fail silently?
;bra vfail ;send verification fail notice? (preferred?)
#PGMENDWRD is the last program word, as calculated by the beginning of the bootloader-1 (see settings.inc)
WADDR is the start word address for the next erase/write
WCNT is the number of bytes received (divide by 3 for words)
In terms of the error: should it fail silently and let you bootload but not overwrite the bootloader? Or should it send the verification error? I see upsides to both approaches, probably for this project (non developers) it's better to give the error.
This code is located here:
http://code.google.com/p/the-bus-pirate ... ader.s#362 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/ds30Loader/src/ds30loader.s#362)
I'm going to try to finish this up now.
i have a note about the protocol at home. When i'm home i could post it here.
I think fail silently; you get then just a verify error afterwards. (wasn't that one of the things we wanted to avoid??) although by normal operations should not get here..
Here's what I came up with, there's still a few issues:
;----------------------------------------------------------------------
; Check address
;----------------------------------------------------------------------
;check that address does not overlap the bootloader
;if(TBLPAG=0){ ;always 0 on this PIC (?)
;write row size is fixed, no need to convert, just add rowsize to starting postion
mov #ROWSIZE, WCNT ;load row size
;don't DEC the number so we can use bra NC
;dec WCNT, WCNT ;subtract 1 from end position
add WADDR, WCNT, W0 ;find the end write address W0=(WADDR+ #ROWSIZE)
mov #BLSTARTWD, WCNT ;load start word into WCNT
;cpsgt WCNT, W0 ;if bootloader start word (WCNT) is > write end (W0) then skip
cp W0, WCNT
bra N, vfail ;send verification fail notice if negative,
;could also bra Main to fail silently
cpsgt (compare, skip greater than) is the obvious choice, but it only works with signed values.
According to a post in the microchip forum, the alternative is cp and then evaluate the C/NC flags:
http://www.microchip.com/forums/tm.aspx ... gt񤜿 (http://www.microchip.com/forums/tm.aspx?m=411409&mpage=1&key=cpsgt񤜿)
But I'm not quite sure what that means, and it only works sometimes when I'm debugging. It's close though. An afternoon is a lot of time to spend on 5 lines of code...
;----------------------------------------------------------------------
; Check address
;----------------------------------------------------------------------
;check that address does not overlap the bootloader
;if(TBLPAG=0){ ;always 0 on this PIC (?)
;write row size is fixed, no need to convert, just add rowsize to starting postion
mov #ROWSIZE, WCNT ;load row size
add WADDR, WCNT, W0 ;find the end write address W0=(WADDR+ #ROWSIZE)
mov #BLSTARTWD, WCNT ;load start word into WCNT
;if bootloader start word (WCNT) is > write end address (W0) then skip fail
cp WCNT, W0
bra LEU, vfail ;send verification fail notice if write > bl start (= is ok because we don't DEC above)
;could also bra Main to fail silently
I think this is it. I tested by hard coding different values and it behaves as expected. I'll test more tomorrow. I guess the LEU or maybe LU bra compare is what I was looking for.
If the ds loader author doesn't have time or isn't willing to make the remaining changes, I can still implement them. Can even do the distribution specific functionality you were speaking of. Just let me know.
Hmm, I spend an evening studying how to write to the flash. I think I can write an installer for the new bootloader. It turns out is it easier then I first though, but it took a while to realize this :S :D I'll write it tomorrow night, but i need your help for testing?
It will do the following things:
- erase the last page
- write the new bootloader and config bits
- erase the second last page
- erase the first page
- write a jump to the new bootloader
- verify?
- reset?
mixed together with some UART and mode LED debugging. If I implement initialize() from main.c and BpInit() from base.c I should be OK?
BTW i tried to look at the check in the bootloader and came up with this (didn't check the syntax much but looks ok):
replace line 75 (svn r195):
.equ WADDR3, W8
add this after line 319 (svn r195):
mov W0, WADDR3
replace line 397 (svn r195) with this block
erase: and #0xF800, WADDR3
sub #0xA800, WADDR3
bra z, prot ; if true protect it
bra nprot
prot: clr DOERASE ; clear DOERASE flag, just to be sure
bra Main ; fail silently
nprot: btss DOERASE, #0
c-equivalent (I hope :D):
if ((waddr3&0xF800)==0xA800)
{ DOERASE=0;
goto Main;
}
I think this will prevent any erase of the last block and also prevent any write within this region. It fail silently (which doesn't upset the casual user, nor do I think during normal operation we encounter this, but better safe then sorry and it is a bad idea to have checks outside your control..) It is getting late so the possibility exist i miss something... *yawn*
Thanks, I'm going to play with the assembly now.
>mixed together with some UART and mode LED debugging. If I implement initialize() from main.c and BpInit() from base.c I should be OK?
Is this for a test firmware? I'm sorry, I'm not quite sure what you mean by this.
@alexdresko - that would be great. I think I found something he's not willing to do. Here's what I wrote in my email:
I have one non-trivial request, I can help and find help to work on this too:
I'd like to add a 'distribution' mode to the GUI that's dead simple for end users. Would it be possible to add an optional distribution configuration file (distro.xml?) that specified the processor, baud rate, bootloader location, etc, and overrides the settings.xml and recentfile.xml? If the config file is found, the GUI would load these default settings (and maybe a specified .hex file if found in the same directory) and start in basic mode.
This would simplify support a lot. I distribute the firmware + bootloader in a single archive for my projects, most people just use the bootloader app included in the upgrade archive. It would be great if I could include a custom settings file that eliminated most configuration except COM port. Maybe this could be part of the existing settings.xml, but with a custom tag to force the use of the settings?
If you could do this, it would be totally awesome. I'll happy send you a current project or preview of a new one.
We'll need to get the author's latest source (might be in his SVN?) because there are a ton of updates since the last release.
If he gets to it before us, I'll still send you the bounty, you've been very willing to help out and I really appreciate it.
No thanks, like to help.
[quote author="ian"]
>mixed together with some UART and mode LED debugging. If I implement initialize() from main.c and BpInit() from base.c I should be OK?
[/quote]
This is for the installer. I need to initialize everything the same way as BP it is in HiZ-mode. To provide the users some visual feedback (like mode led on and some kind of progress bar on the terminal)
Ah, you mean an internal installer? A firmware that you upload and then it writes the new bootloader? I thought you meant an upgrade script for the PC. That would make a lot more sense.
Yes, those are the setup functions you'd need. baseio or baseui has the actual UART functions, and the macros for LEDs are defined in the hardwarevx.h files.
I really like your ASM, it's a lot less 'mov-je' (mov-ie?) than my solution. I'm curious though, why did you & with f800 and not a800? Anything over a800 should be an invalid write.
I'm torn on failing silently. On one hand, a verification error could provide feedback if there's an incorrect setting in the loader app or the wrong firmware was used, on the other hand it might make people think the chip is broken when it isn't. Silent is probably OK because the loader app is the primary line of defense against overwrites.
Is the sneeuw ever going away? I want to go to the market but the streets are pure ice, I'm not crazy enough to ride my bike on that!
It is difficult to explain, but i try anyway:
begin of page
A800 = 1010 1000 0000 0000
F800 = 1111 1000 0000 0000
=================== &
A800 = 1010 1000 0000 0000
end of page
ABFF = 1010 1011 1111 1111
F800 = 1111 1000 0000 0000
=================== &
A800 = 1010 1000 0000 0000
This only matches the range we need.
If you and it with 0xA800 the following statemant is true:
8800 = 1000 1000 0000 0000
A800 = 1010 1000 0000 0000
=================== &
8800 = 1000 1000 0000 0000
BTW you don;t receive an verification error if you fail silently (bra main), it never reaches the verify subs.
Not much snow here ;) besides when using a car it prevents you from falling :P
Thanks for the explanation. I had the order of the SUB instruction backwards. That makes more sense, it's OP2-OP1, so 8800-A800 would be negative. I think the status Z flag (Z test) would be false if it's negative though, and the N flag is set.
The literal (#0xa800) with SUB can only be 10bits maximum. I think this will give unexpected results because it does not treat it as a 16bit unsigned number. The easy solution is to mov 0xa800 (also defined as #STARTADDR) to an unused W register. This is from the table on page 218 of the 24Fj64GA002 manual.
I imagine two bootloader problem scenarios:
1. User checks 'overwrite bootloader' and uploads firmware that includes new config words.
2. Runaway data, accidental reset, garbage data, etc. The checksum is only one byte, so 1 in 256 runaway situations could result in loss of bootloader (less because it would also have to be correct instruction to erase the correct page etc, but it's possible).
Here is a working solution that's a bit more involved that I'd like, but it also catches cases where write or erase address is 0xa7C1 and higher. This goes before check command:
;----------------------------------------------------------------------
; Check address
;----------------------------------------------------------------------
;check that write and erase range does not overlap the bootloader
;if(TBLPAG=0){ ;always 0 on this PIC (?)
;check the start address
;if write start address (WADDR) >= bl start address (WCNT) then error
mov #STARTADDR, WCNT;reuse WCNT to hold start address
cp WADDR, WCNT ;compare the start address, does it overlap?
bra GEU, bladdrerror ;yes, then branch to error handler
;check the end address
;write row size is fixed, add rowsize to starting postion
mov #ROWSIZE, W0 ;hold row size in W0
add WADDR, W0, W0 ;find the end write address W0=(WADDR+ #ROWSIZE)
;if write end address (W0) is <= bl start address (WCNT) then OK
;= is ok because we don't DEC after adding, write 10 bytes to 10 = end at 19
cp W0, WCNT ;compare end address, does it overlap?
bra LEU, bladdrok ;continue to erase and program if no error
;handle the address error
bladdrerror:clr DOERASE ;clear, just in case
bra vfail ;Main ;fail silently
I've been testing this, so I had it fail with a verify error. This shows up in the ds30 Loader app, it tries three times then quits. I'm leaning towards keeping the error because it is accurate: that part of memory was not erased or written correctly.
Here is the ASM guide I've been using. This is for my own reference because it's really hard to find again:
http://ww1.microchip.com/downloads/en/D ... 70157C.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/70157C.pdf)
--------------------
Upgrades are pretty stable at this point. If you don't have any garbage in the upper page (no translated firmware, no nightly compiles used) then you can upgrade without erasing the config words. To verify, click the read chip button in the PIC24F quick programmer utility. Open the PROGMEM.TXT file that is created, scroll to the bottom and check the lines from 15000, they should be blank (except the last line):
015000 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
...a bunch more lines...
0157E0 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00
0157F0 FF FF FF 00 FF FF FF 00 DF F9 00 00 7F 3F 00 00
If you have a clean upper page, erase the chip and upload the new bootloader with leave 'preserve flash configuration works on erase" checked. The upper page will be written correctly with no risk of losing the configuration. If it isn't blank, uncheck the box, erase the chip, then upload the v4 bootloader. Follow my previous post to access the new bootloader and upload the bus pirate firmware to erase the old bootloader.
This is pretty stable. I haven't had a single problem. It's also possible to revert to the old bootloader with the new one (uncheck the preserve config bits box to erase the v4 from v2 or the upper page won't get erased correctly). I wouldn't recommend it for everyone yet, but it works great.
-----------------
The only thing currently holding up testing and deployment is the bootloader application. The author added configurable bootloader placement for us, but it's still a little flakey. It doesn't recognize the updated bootloader placement setting without a bit of trickery, and there's a ton of settings that have to be configured each time.
To use the new app, grab the latest compile from our SVN:
http://code.google.com/p/the-bus-pirate ... tly/loader (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/firmware/v4-nightly/loader)
(no install required if you keep all the .dlls in the same folder as the application)
Open it.
Open the HEX file to program.
Configure it as shown in the attached image.
Go to View->advanced mode
Click on the advanced tab
Check custom bootloader placement and set it to 1 (see other image).
Go back to the basic tab
At this point, you still can't program because the application needs to parse the HEX file again according to the new bootloader placement. This is a bug I think the author will fix soon. To get it to reparse, you can close and open the app again, or just go to options->debug mode (the parse progress will display in the box).
Now check the Write Program box on the basic tab
click the download button
As you can see, this is a whole bunch of configuration that will have to be done by every user for every upgrade. This is why I want to add a distribution config file that sets as many defaults as possible. The program does store settings on a per-file basis, but each upgrade is a new file.
NOT FOR GENERAL USE!!! TESTING ONLY!!!
Here's a package with the bootloader upgrade, compatible firmware, and ds30 Loader application:
http://code.google.com/p/the-bus-pirate ... 4.test.zip (http://code.google.com/p/the-bus-pirate/downloads/detail?name=BusPirate-firmware-v4.test.zip)
NOT FOR GENERAL USE!!! TESTING ONLY!!!
Hopefully one of my final posts on this topic :) Requested changes for ds 30 Loader application:
Goal: preconfigure the GUI for quick updates from a distribution archive.
The application stores some settings in a settings.xml file. In the most recent update the author added a feature that remembers the settings for each firmware file the app loads in a recentfileX.xml. The settings in recentfileX.xml are matched on the full file path, so it's not helpful in our situation.
I think the easiest thing is to add a 'distribution' tag to the settings.xml file which causes settings to be loaded directly from settings.xml instead of the recentfileX.xml. These are the values (tags currently stored in recentfileX.xml) that I need to set:
115200
PIC24FJ
64GA002
true
1
If we wrap the settings in a tag then we probably don't need an additional tag.
Optionally, it would be nice to include a file name based on a relative path (current directory). Currently it's stored like this:
E:Workbus-piratetrunkfirmwarev4-nightlyBPv3&v2goBPv3-Firmware-v4.hex
It might be nice to do something like this that would load a firmware from the current directory automatically:
BPv3-Firmware-v4.hex
I'm not sure if it's possible for anyone but Mikael to make the changes at the moment because there doesn't appear to be a source repository for the project. I've asked about it though, and will let you know what I hear. He usually writes after work northern EU time.
One minor change. Precalculated the end position so there's no need to do it on the chip every time:
.equ BLCHECKST, ( STARTADDR - (ROWSIZE) ) /*precalculate the first row write position that would overwrite the bootloader*/
That eliminates the need to add row size and compare to STARTADDR every time:
;check the start address
;if write start address (WADDR) >= bl start address (WCNT) then error
mov #STARTADDR, WCNT;reuse WCNT to hold start address
cp WADDR, WCNT ;compare the start address, does it overlap?
bra GEU, bladdrerror ;yes, then branch to error handler
;check the end address
;write row size is fixed, any writes at (bootloader start-63) are an error
;if write end address (W0) is <= bl start address (WCNT) then OK
;= is ok because we don't DEC after adding, write 10 bytes to 10 = end at 19
mov #BLCHECKST, WCNT ;first row write postion that would overwrite the bootloader
cp WADDR, WCNT ;compare end address, does it overlap?
bra LEU, bladdrok ;continue to erase and program if no error
;handle the address error
bladdrerror:clr DOERASE ;clear, just in case
bra vfail ;Main ;fail silently
Here's the latest C# source from the ds30 Loader author:
http://www.whereisian.com/files/ds30_loader.zip (http://www.whereisian.com/files/ds30_loader.zip)
I'd like to add a section to settings.xml that will be used if there's no recentfileX.xml present. That's not as specialized as a distribution mode, it just defines the default startup settings. Since most users unzip the upgrade archive to a folder, there won't be an existing recentfileX.xml and the defaults will be used.
How about storing an recentfilex.xml in the archive? :D
The recentfile.xml is full-path qualified, so the file would have to match the same drive letter and location stored in the XML.
I'll make the changes to the GUI this weekend.
I almost finished the installer, but I came to a point where it is not safe for me to further test it (writing the real bootloader to the correct location and alter the reset vector)
The current build writes a test pattern (from firmware.h) to a 'safe' location (0x9000). I saw it erases the page (or perhaps the other bootloader did it?) and write the test pattern correctly (read it back with the old bootloader). for the final build firmware.h should be altered with the correct firmware and load adress and the commented-out code should be enabled. And perhaps some bugs fixed ;)
I already put it under the same license as the buspirate and gave credit for the pieces I did use (mostly from the buspirate project and some asm lines from the C30 loader).
everything should be in de archive.
Thanks Alex & Sjaak
No problem! Even got some more ideas to implement!
I forgot to mention is it lighting fast. Programming is done in a blink of an eye. So it is as safe as i can be...
Hi,
I was looking at the bootloader protection, you don't need that 2nd check. The first one catches both erase and write operations in the bootloader area.
Instead of bra vfail you could add a new response:
.equ BLPROT, 'P' /*bl protection tripped*/
;bra vfail ;Main ;fail silently
SendL BLPROT
bra main1
Here's the changed code that goes into c# engine to handle the new bl protection response. I will include this in the next official release.
public const char cBlProtTrip = 'P';
//---------------------------------------------------------------------
// ProcessWriteResponse()
//---------------------------------------------------------------------
static private void ProcessWriteResponse( clsSerialPort pobjPort, ref int piRetries, int piTabLevel, string pstrWriteType, ref bool pbRetry, ref bool pbResult )
{
int iResponse = -1;
pbResult = false;
// Get response
bool bGetResponseResult = false;
iResponse = GetResponse( pobjPort, ref bGetResponseResult );
if ( bGetResponseResult == false ) {
return;
}
// Check response
if ( iResponse != cOK ) {
if ( ++piRetries == 3 ) {
OnDownloading( new clsDownloadingEventArgs(clsDownloadingEventArgs.EventType.error, "download failed", -1) );
return;
} else {
if ( iResponse == cChecksumErr ) {
OnDownloading( new clsDownloadingEventArgs(clsDownloadingEventArgs.EventType.error, "checksum error," + piRetries.ToString() + " try", -1) );
pbRetry = true;
} else if ( iResponse == cVerifyErr ) {
OnDownloading( new clsDownloadingEventArgs(clsDownloadingEventArgs.EventType.error, "verify error," + piRetries.ToString() + " try", -1) );
pbRetry = true;
} else if ( iResponse == cBlProtTrip ) {
OnDownloading( new clsDownloadingEventArgs(clsDownloadingEventArgs.EventType.error, "bl protection tripped", -1) );
pbRetry = false;
return;
} else {
OnDownloading( new clsDownloadingEventArgs(clsDownloadingEventArgs.EventType.error, "unknown response," + piRetries.ToString() + " try", -1) );
pbRetry = true;
}
OnDownloading( new clsDownloadingEventArgs(clsDownloadingEventArgs.EventType.info, "Writing flash...", piTabLevel) );
}
} else {
pbRetry = false;
}
pbResult = true;
}// ProcessWriteResponse()
Welcome to the forum Mikael. Thanks, I'll add that, great addition.
Well, the ds loader changes weren't really all that bad. The hardest part was figuring out WHERE to make the changes. Here's a list of changes I made.
• I fixed a small bug wherein ds loader would crash if an invalid hex file was loaded. I stumbled across it because I needed a hex file to test with while I wasn’t connected to the internet. At the time, I simply created a text file with a .hex extension. Not something that should happen often, but changing the following line…
(http://http://img199.imageshack.us/img199/1868/bugnr.jpg)
….to the following code fixes the problem well.
(http://http://img189.imageshack.us/img189/8159/bugfixed.jpg)
• Not sure if the following line is a good idea. Check what the function does and consider the consequences of hitting this line when turning on/off advanced mode. I’m concerned that if someone goes from advanced mode back to normal mode, it will negatively affect some of the settings. Again, if you check what the code in ResetSettingsToDefault does, you’ll probably be able to determine if this is an actual issue. Or just test it.
(http://http://img42.imageshack.us/img42/9682/resetj.jpg)
• One of your concerns was that users would accidentally check the Overwrite Bootloader option. As you’ll see in below, the settings.xml file allows you to effectively disable this checkbox from being clicked. Run this through a couple of scenarios and make sure that this is a valid thing to do. I know it’s not something you asked for, so I might not should have implemented it the way I did.
• I believe the way I did things, I also eliminated the bug that required you to close the program to make it reparse the file. You’ll have to test it though and let me know.
• The settings.xml file supports relative paths now, at least when opening the settings.xml file the first time. So you can have BPv3-Firmware-v4.hex for the filename, but when you close the application, ds loader will replace it with the full path to the hex file. I can change how this works to save a relative path instead of the full path, but you’ll have to tell me if that’s necessary.
• I thought about making it so ds loader would automatically load up all .hex files in the current directory when the application starts, but that would force the application to parse each file that it loads. Seemed a bit overkill so I didn’t do it. Lemme know what you think.
• I didn’t modify the structure of the VisualStudio solution, but I SO want to. It bugs me how he’s got the directory structure laid out and that the ghelper.dll isn’t included with it.
• Though the new DefaultStartSettings will correctly allow automatic configuration of the custom boot loader placement, I do not know if those settings will be applied if the Advanced Mode is not turned on. As I have implemented these features, the Advanced Mode remains off if it was already off when you load a new file. I didn't look far enough into the code to find out.
• You might want to let the original author of ds loader take a look at the changes I made for final approval. I didn’t exactly follow all of the coding conventions he used, but my code is very clean. In any case, now that there are 2-3 people working in the ds loader code, it really needs to go in some kind of source control. Passing code around like this is a bad idea.
• Here are the settings currently supported by the settings.xml file.
false
false
true
343
459
BPv3-Firmware-v4.hex
115200
PIC24FJ
64GA002
true
1
true
true
I’m fairly familiar with the ds loader code now so I’m comfortable making additional changes as needed.
If all goes well, you'll find a link to download the modified code and compiled assemblies at:
http://www.box.net/shared/v0sfrgeisu (http://http://www.box.net/shared/v0sfrgeisu)
Fantastic work Alex, thank you!
The advanced settings reset is a concern. I can see it either way: preserving advanced settings to avoid unintended errors, or resetting because they aren't visible any more. My primary concern is: will the advanced settings stick when the user starts the programmer for the first time, the rest I can leave to Mikael. I'll do some testing on this.
Thanks for the overwrite bootloader switch, that's a great addition. Between that and the built-in bootloader protection it should be as close to fool-proof as we can get.
Accepting a relative path on first startup is perfect. After that the recentfileX.xml will be used instead, which should include the correct full-path for the user's system.
Let's not parse all the files for now, the relative path on first load is everything I wanted an more :)
I'll do some testing with startup and advanced mode, and wait to hear what Mikael has to say.
I added the original source archive to the Bus Pirate SVN, then copied your source archive over it and created a patch. This code does not contain the bootloader protection function that Mikael posted a few posts back. Here's the SVN and patch:
http://code.google.com/p/the-bus-pirate ... 0%20Loader (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/bootloader-v4/ds30%20Loader)
I also talked to Mikael about SVN today, so hopefully there's an official ds30Loader SVN soon. For now, I can add everyone to the Bus Pirate project if you send me a google registered email address.
I'll test Sjaak's updater now.
Sorry, google didn't like the space in that link. This should get you close:
http://code.google.com/p/the-bus-pirate ... tloader-v4 (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/bootloader-v4)
Ian, I hope you understand what i did wrote ;) I tried to add as much comments (normally not my style ;))
The byte order for the firmware.h should be the same order as the loader sends them. If it is convienant it could be changed easily (to support an auto-build process).
A few comments on the installer:
It should probably be under GPL. The ds30Loader code is GPL so that 'infects' the other code with GPL as well. The Bus Pirate is public domain (free for any use) with the idea that you can prototype with the Bus Pirate, then take the protocol source code and implement it in you own project without any licensing restriction whatsoever. The installer isn't part of that, so I have no problem with it being GPL.
I started writing about erasing the next-to-last page, but I think I found an issue in how I used the bootloader. The user jump instruction for the new bootloader goes in the last two instrucitons of the next-to-last page. The firmware includes 0xff0000 NOP instead of the 0xffffff NOP.
The ds30 Loader firmware has a timeout delay instead of the jumpered pins method used on the Bus Pirate. I just set the delay to 1ms instead of eliminating it. In all my testing everything works fine, but I'm not sure why really.
The jumper between the pins allows the bootloader to start (else it jumps), then it trys to get a byte from the UART for the delay period (i set it to 1ms), if it's not a hello, it exits to the user code. If the chip is blank, these are NOPs that walk back to the bootloader (thus the installer must erase the next-to-last page too). If there is a user program, then the instructions are a branch to the location where it starts. Right now I have no problems entering and using the bootloader on a programmed chip, but I don't know why. It should time out and quit to the existing firmware after a short period if that instruction is already programmed! That might explain a painful debugging experience I had last week. I need to just remove the timeout, it's of no use to us with the jumper.
The point is: erase the next to last page so it returns to the bootloader on an upgraded chip, instead of whatever random instruction happens to be already programmed.
Also: do you have a way to turn a .hex into byte code like that? Maybe MPLAB already outputs it but I'm unaware. IF not, it shouldn't be too difficult to write a PERL script to do it.
Ah, I remember. If it times out then the chip resets:
mov #__SP_init, WSTPTR ;reinitialize the Stack Pointer
We need to keep that for upgrades with the existing bootloader (you can activate it whenever on a blank chip).
I could rewrite it so it is my 'own' code. The it should be ok to release it under the same license as the buspirate? It is all documented on microchip.com. I dunno if a couple of asmcodes BTW are covered/infected by the gpl.
Ferase(0xA000); should erase the second last page. I indeed forget the two instructions before the loader. I looked at the current code and the jump to userapp is located just before start??
I think the delay should stay as it is also used as communicationstimeout.
I'll try to come up with a script to export a .hex to the needed include.
ian: that line doesn't reset the device, it just resets the stack pointer. If we would reset after comm. timeout, we would NEVER get to the user application.
nice job alex!
1. Great you found it, I solved it slightly differently, setting objHex to null if parse failed in DoParse(). I also added some code in repaint to draw a cross if objhex=null.
2. As Ian wrote, settings are reseted because they're not visible.
3. (There's also the pic side protection)
4. I think that was already fixed in the version you got. Check leave events of the textboxes
5. -
6. Fixed what I think is a better structure with a single solution. But the ghelper won't go in it.
7. The settings will be applied.
8. I'm working on a svn server, test it here:
https://mrmackey.no-ip.org:444/svn/ds30 ... k/pc-side/ (https://mrmackey.no-ip.org:444/svn/ds30loader/trunk/pc-side/)
l: guest
p: G
9. -
The svn server worked.
Here's a sequence of events that explains my concern about advanced mode:
1. I start ds loader. It is in normal mode by default.
2. I go to Advanced Mode and make changes there such as enabling the custom boot loader placement.
3. I turn off Advanced mode.
4. I apply the hex to the pic.
From what I can tell, once you go into Advanced mode and make changes, you have to apply the hex while in advanced mode, or you'll lose your settings. I haven't tested any of this on my BP though, so I'm not sure.
Dll files can be added to a VS solution by way of "Solution Folders".... See below for an example of how I usually do this. I added the ghelper.dll to a folder called "ReferencedAssemblies.
http://www.box.net/shared/yeuvx6l3cv (http://http://www.box.net/shared/yeuvx6l3cv)
looks like I made some huge mistakes in my code :S The problem was a bad testpattern (not suitable for testing bleh!). I now used a .hex of the 217 svn and i noticed the error and (I think) I corrected it.
Anyway I included it (the bootloader of svn217') in the firmware.h.. I Also included an .html file (sorry no perl on this windows box) which convert the bootloader to an array which can be used in firmware.h. Select the start and up to the last full 16 byte line.
first line to be selected:
:105000002F8C20004227A9004507A90042A7AE0027
last line to be selected:
:1057E000FFFFFF00FFFFFF00FFFFFF00FFFFFF00C5
The .html should automagicly add the last 4 word together with the fuses. The .html also handles the byte to 'program word' conversion. I didn't saw a way to use objdump to dump the relevant parts...
As far as I know this attached package should now behave as expected, but I couldn't test it in real (stil haven't got a pic programmer). I also changed the commented out section to be correct byte to 'programword' conversion.
So Ian, could you please please test it? :p please alter the fwlocation to 0xA800 and uncoment the section in main.c
If it works correctly I'll rewrite the flash.s to comply with the creative 0 license (hadn't the time for it tonight!)
Great job, I made a few tweeks to the installer and it works! I uploaded installer with the old bootloader, ran the install, then uploaded the v4 firmware with the ds30 Loader GUI.
Nice thinking on the javascript converter too. I do that a lot, Javascript is one language everyone has an interpreter for, and it's ready to be deployed on the web with no fuss!
I put the installer into the SVN:
http://code.google.com/p/the-bus-pirate ... 4/upgrader (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/bootloader-v4/upgrader)
If you give me a google code registered email I can give you commit permission to submit your changes directly to the SVN.
Changes:
I added a DEBUG define. If enabled it uses the 0x9000 write location and skips the jump instruction erase/write.
I added a repeating warning. Any key brings up the user message, 'Y' continues, you're then prompted to press Y again if you're sure. Any other key sends it back to the main user message.
The jump instruction needs to have the second instruction as 0x0000, so I zeroed these three bytes in the jump instruction row write.
I added message to upload v4+ firmware to complete the upgrade.
I also though of entering 'yes' or 'I agree' instead of hitting enter twice for the final version. I'm not satisfied with the javascript tool but I had to :) I think it is not suitable for auto-building.. But it did the job ;)
Good additions, although the debug define could be left out, but on the other hand why not..
I try to register an email with google code later on. (Shall i also add the other changes (other topic) in the trunk? :P)
Please hold off on the other changes because we need to make room for them with the new bootloader first. We should but those in a v4 branch that's compatible with the new bootloader.
What do you BTW mean with serial comma's?
I'm not a native speaker :( and my english is prolly better then your dutch :P
Ok. I'll wait for the next release. How many room is there left for new code (using the new bootloader)?
I'm SURE your English is better than my Dutch :) I edit papers for Dutch friends, and serial commas are one of the most common errors. English has a comma before 'and' in a list of three. If I write a list in English it's one, two, and three. Maar in Nederlands een, twee en drie.
I'm really sorry, no offense was intended. Your English is fantastic.
Wasn't mend to offend anyone. Just take it with a little grain of salt (bad translation of a dutch saying ;)) (i love bad translations)
I like this kind of comments in sourcecode, but I didn't know what serial comma's were. Never too old ;)
alex: your concern is correct. May I suggest my own suggestion again? :)
A separate distribution file containing all fields from recentfile.xml and also for every field
there's a tag saying if the user is allowed to change, example:
COM1true115200falseAh, I thought you meant to include the ghelper source. What you suggested is great, I've implemented that now!
@sjaak - We'll gain at least one extra page. I'm not sure of the total space because the compiler likes to page align some things so I'm never sure exactly how much is still available. I used to think that data verify errors in the last page were just a sign of the firmware growing too large, but then here we are now... I think there's about 1/4 to 1/3 of the flash still available after the fix. I'm not sure the memory use gauge in MPLAB takes into account the bootloader reserve space in the .gld linker file.
@mackey - I'm sorry, I posted this in the wrong thread:
My SUGGESTIONS, some may be overkill
* A single file dist.xml
* Hex filename in dist.xml is stored without path, it's used as a filter when
browsing for files.
* dist.xml contains a crc checksum of the new firmware (hex-file)
* The file contains all fields from recentfile.xml and also for every field
there's a tag saying if the user is allowed to change, example:
COM1true115200false* A crc cheksum of dist.xml settings
* A custom built version of the gui that requires dist.xml to be present
Micke
-----------
I just downloaded and compiled the lastest SVN ds30 Loader and tested it with a bootloader placed by Sjaak's installer.
Reparse after changing the placement works great!
Bootloader protection error recognition works.
Load firmware from local folder in the settings.xml also works.
It looks like the defaultsettings code isn't in the svn yet, can I help with that?
For the advanced settings mode: would it be possible to have a tag to startup in advanced (to be consistent user-interface wise)? How about a notice in the output box that the advanced settings have been cleared when going to basic mode?
I'd also like to make the installer more portable and generic. It's a nice addition to the ds30 Loader package, an easy way to upgrade the bootloader in the field.
Sounds good! :)
I merged alex's addon. But I couldn't keep my fingers away, I expanded it
with default values for all settings + allow flags as I suggested earlier (twice) =)
Added an information output when switching to basic mode. Good suggestion!
Maybe there should even be a messagebox with yes/no buttons...
Also I'm not the best friend with svn at the moment. I've started all over
on the ds30 Loader trunk.
Your last line, thats towards sjaak right?
btw, is there any can module or something to the pirate?
btw2, why is there no smileys in the forum?
Yup, last line was to sjaak.
There is no CAN module at the moment. There has been various discussion of using the Microchip SPI->CAN transceiver, but no real progress. I'd work on it, but I don't have hardware to test it with.
I'll check the smileys, there's lots of settings but I've ignored most of them.
The bootloader is pretty much portable I think. I could expand that it can write more then 1 page at a time and make it more conifgurable where to put the 'payload'. A great addition would be hex2h convertor.
I don't think the gauge doesn't take the bootloader and such not into account. The last patch i wrote it was pointing to 75% i think, but that hits the 0xA800 boundry. I haven't tried any optimizing flags to the compiler (i think optimizing would kill timecritical subs).
BTW smileys should be enabled, but I guess I have the age to recognize textbased smileys :P
Just checked the 'memory gauge' it indeeds doesn't take any offset into account. You can notice it when you hit F10 and look at the output window. It displays the offset and length. It only accumulates just the lengths.
About optimalization (dunno if optimizing breaks something, had good experience with -O2 on the gameboy advance (demos and such). AFAIK it can break timecritical things)
When I compile the svn 221 these are the byte used:
none bytes used = 45540 (74%)
-O1 bytes used = 37230 (60%)
-O2 bytes used = 40278 (65%)
-Os bytes used = 35817 (58%)
-O3 bytes used = 51501 (85%)
this can also help save some bytes ;)
Btw i noticed the first 0x800 bytes of the ram are excluded by the linkscript, you know why? it is in the normal linkscript and your's (the one used with the 'vintage' loader)
I got the latest ds30Loader from SVN and compiled. The default settings work great! Here's a default settings file for the Bus Pirate firmware:
http://code.google.com/p/the-bus-pirate ... programmer (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/bootloader-v4/programmer)
Downloading the firmware or checking for the bootloader causes an error, I assume related to a missed setting. I'll see if I can find it:
"Input sting was not in a correct format".
System.FormatException: Input string was not in a correct format.
at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
at ds30_Loader_GUI.frmDS30Loader.SetupDS30LSettings() in E:Workds30LoaderguifrmDS30Loader.cs:line 1086
at ds30_Loader_GUI.frmDS30Loader.Download() in E:Workds30LoaderguifrmDS30Loader.cs:line 402
at ds30_Loader_GUI.frmDS30Loader.btnDownload_Click(Object sender, EventArgs e) in E:Workds30LoaderguifrmDS30Loader.cs:line 1558
at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
I'm working on the install instructions now. When the GUI is going, I'll post the upgrade guide and ask for alpha testers.
I'm sorry, I didn't even try a download before i commited. I've fix that exception by adding hardcoded nonempty defaults to some string settings. I also added some code to catch parse exceptions in SetupDS30LSettings().
The svn is updated and the binaries can be found here:
http://mrmackey.no-ip.org/elektronik/ds ... loader.zip (http://mrmackey.no-ip.org/elektronik/ds30loader/files/ian/ds30_loader.zip)
edit: maybe you should lock the advanced setting to true?
You beat me to it :) I was just debugging the code and thought that maybe the null values were causing a problem. Thanks, I'll get the fresh source now.
I thought it was locked to true, I'll do it if it's not.
Hey hey, everything fell into place. It all works nicely. I tested in v3 and v2go, all seem file. I've uploaded the upgrade package here:
http://code.google.com/p/the-bus-pirate ... update.zip (http://code.google.com/p/the-bus-pirate/downloads/detail?name=v2tov4-bootloader-update.zip)
I'll post the call for testers now.
Sorry for the choppy and buggy development. I have a lot of open "support cases" at the moment, at the
same time I've done some major rework of the code in the engine. I have reduced code by approx 30%.
A lot of the hex parsing and writing code is common for most firmwares...
Here's a new version that I hope will be the next official release:
http://mrmackey.no-ip.org/elektronik/ds ... loader.zip (http://mrmackey.no-ip.org/elektronik/ds30loader/files/ian/ds30_loader.zip)
https://mrmackey.no-ip.org:444/svn/ds30 ... k/pc-side/ (https://mrmackey.no-ip.org:444/svn/ds30loader/trunk/pc-side/)
(The old version should be good enough for alpha testing)
This time you beat me to it, you replied while I was typing :)
WOW! we realized it in a short time!
Good work guys!
@everyone - Thanks for participating in this effort. It was fun to be part of a development team with so many talented people. We really brought a lot of different things together in a short period.
One of the perks of running my blog is that I can send freebies to contributors. I'll send everyone any future Bus Pirate hardware, or if you prefer, a different monthly project. Please don't be shy about asking, I sometimes forget with the number of support issues and amount of development occurring day-to-day.
@sjaak - Are you ready to test it on your Bus Pirate? ;) I'm really happy with everything and haven't seen errors in my tests. If you brick it, NL post is only 1 day to and from, I can fix it and have it back to you in a day or two. I don't think that will happen though :)
Forgot to add, here's my upgrade post: http://dangerousprototypes.com/2010/01/ ... candidate/ (http://dangerousprototypes.com/2010/01/13/bus-pirate-bootloader-v4-upgrade-release-candidate/)
I'm feeling confident, but first I'm rewriting the flashsubs. let me first test that and then on to version 4! I also see some errors (it is missing some return statements, but it doesn't hurt much) in the current flash sub.
BTW: Any stats on the (new) memory usage?
It was not only fun, I learned a few thing about VS and .NET from Alex, thanks!
Where you from Alex? I'd like to add you to my contributors list on the homepage
for the gui code.
Hope I get my pirate soon so I can test to :)
Looks like I smashed the bug. I also altered the main a bit. You must type exactly 'Yes' to proceed. Please take a look at the 'screenshot':
DS30 Bootloader installer v0.2 (very ALPHA)
(C)hris 2010
Released under Creative Commons null license
Type 'Yes' to program the new loader
or disconnect power if unsure (no harm done)
Upgrade cancelled.
DS30 Bootloader installer v0.2 (very ALPHA)
(C)hris 2010
Released under Creative Commons null license
Type 'Yes' to program the new loader
or disconnect power if unsure (no harm done)
Yes
Sit back and enjoy the show
Erasing 0xA400... done
Erasing 0xA800... done
Writing row 0 1 2 3 4 5 6 7 done
Erasing 0x0000... done
Writing new jump instruction to row 0... done
Upload v4+ firmware with the ds30 Loader app to complete the upgrade.
Light up a candle, say lots of prayers, keep your fingers crossed, and reset you
r buspirate.
HiZ>i
Bus Pirate v3
Firmware v4.0
DEVID:0x0447 REVID:0x3043 (B5)
http://dangerousprototypes.com
Since i did upgrade the bootloader (how else I'm supposed to get a good screenshot??) I loaded the new firmware. But during flashing the app crashed (I think only the GUI, because the USB led was still flashing during the popup) I forgot the write down the error because i was scared. Second try it didn't crashed. I really like the app btw!
An idea of improvement: when an timeout occurs, restart the bootloader if the jumper is present? I scared to dead when it didn't respond after checking the bootloader!! Also alter the bl version number I think (mackey you agree?)
SVN also updated (did I forget anything Ian?)
Looks great. I made a few minor changes, tested them, and uploaded to SVN:
*created a character check function to handle the user input comparison. I also made it case insensitive so any YeS will work.
*Shortened 'Writing new jump instruction to row 0...' to 'Writing row 0...' because that's less time the chip spends between erasing and writing the new jump vector (less danger of brickage).
*Added "Success!" message at end.
Yes, you only get one shot to connect to the bootloader, then it needs a reset. It's different than the old program that could connect multiple times, any time.
We might consider adding some features to a future bootloader upgrade (since we have such a nice installer and plenty of space):
*Support multiple connects
*Dump PIC memory
*Run command to exit programming mode?
Case insensitive is a bad option in my opinion, because you need to explicit know what you are doing. Perhaps a bit of an overkill an paranoid?
I got an other idea. When debug build is selected in the IDE the symbol __DEBUG is defined, shall we replace the #ifdef DEBUG with #ifdef __DEBUG ? downside is it isn't configurable with the hardware.h.
Multiple connect is something we need to change in the bootloader. I think adding the jumper check after the timeout:
.. timeout
if (jumper) goto begin
.. jump to usercode
I'll look into the remaining issue tonight
The extra features were just ideas, no need to jump into it now.
Case sensitive is fine, we can just comment out that line. Let's add a warning that it's case sensitive though so people know.
We can take out the debug features all together if you like.
Good idea, we can make it jump back if there's still a jumper.
We could also add a prompt to press space to reset the bus pirate into bootloader mode from the upgrader. Saves a reset, but risky if user types stuff after the reset.
I think it is fine not to reset after flashing: you need to switch from the terminal app to the ds30loader app. In windows (and i think linux also) a program exclusivly claims the serial input so you must manually release it and switch to the other app, connect.
Debug is fine as it it but the ide had a special menu feature for it (however i dunno how many know this feature :P)
There seems to be a common issue with the bootloader not connecting to the ds30 Loader app after an upgrade. Any thoughts? I've requested a dump of a chip with this problem so we can take a look and see if it's an upgrade issue, bootloader issues, or operating system/ds30loader issue.
One successful upgrade, three failures (so far):
http://dangerousprototypes.com/2010/01/ ... candidate/ (http://dangerousprototypes.com/2010/01/13/bus-pirate-bootloader-v4-upgrade-release-candidate/)
I've tested and retested, but I can't make this happen on my system so I suspect a PC/operating system error (but that's wild speculation).
Hi Ian, hi all!
Just coming over here from:
http://dangerousprototypes.com/2010/01/13/bus-pirate-bootloader-v4-upgrade-release-candidate/#comment-1678 (http://http://dangerousprototypes.com/2010/01/13/bus-pirate-bootloader-v4-upgrade-release-candidate/#comment-1678)
Something I noticed after the mentioned problems is that the USB LED never lights when I try to search for the bl with ds30loader! I'm not sure if it should or if it's just to short for my eyes though. :-)
(The used port is correct and the baudrate (for programming) is fixed at 115220, right? I didn't found anything in the settings.xml to change this baudraute... Only the terminal baudrate is configurable.)
Salut, Jörg
Hi again!
I'll try to get a dump out of my "dead BP" too (this evening).
In the meantime: What are we supposed to flash at which address (and with which flags/fuses burned) into my BP with ICD? :-)
Could we perhaps burn a "complete bl + v4" image or should we try the bl alone?
I think the later will get stuck at the same step when trying to connect with ds30loader...
Something I noticed after the mentioned problems is that the USB LED never lights when I try to search for the bl with ds30loader!
This seems to be normal. All other options will also not flash the USB-LED...
Salut, Jörg
[quote author="ian"]
There seems to be a common issue with the bootloader not connecting to the ds30 Loader app after an upgrade. Any thoughts? I've requested a dump of a chip with this problem so we can take a look and see if it's an upgrade issue, bootloader issues, or operating system/ds30loader issue.[/quote]
Here is my dump of a failed update. Hopefully I have done it correctly.
I have retried using an XP machine instead of VMWare with the same result.
Cheers, Ian.
I think I found it. Looking at a dump would be best, but can reproduce the issue on A3 silicon, but not B4/B5. Are any of the upgrade failures A3? I'll look at the errata, also the old bootloader must make mention of this bug because it was designed for the old chip.
[quote author="2lostkiwis"]
Here is my dump of a failed update. Hopefully I have done it correctly.
I have retried using an XP machine instead of VMWare with the same result.
Cheers, Ian.
[/quote]
Pretty sure the problem is configuration bits. Mine are all reset to 1, and looking at the BPv3-blupdater-v4.hex file some are 1 and some are 0. What could I have done wrong to cause the bits to be erased to zero?
Cheers, Ian.
Thanks! I'm dumping and running a diff now.
[quote author="2lostkiwis"]
Pretty sure the problem is configuration bits. Mine are all reset to 1, and looking at the BPv3-blupdater-v4.hex file some are 1 and some are 0. What could I have done wrong to cause the bits to be erased to zero?
[/quote]
Please ignore this - operator error :-)
I believe they are programmed to 81D7 3F5F.
Not sure how I can find my silicon id with the bp in non working state.
[quote author="2lostkiwis"]
Please ignore this - operator error :-)
I believe they are programmed to 81D7 3F5F.
Not sure how I can find my silicon id with the bp in non working state.
[/quote]
Same here. Need my ICD to get the silicon revision. :-(
(Part # says 24F64GA002 if this helps.)
Jörg
I'm going to step through the process with A3 and B4 pics and create dumps.
You do have configuration bits (slightly different format and checksum):
:1057F000FFFFFF00FFFFFF00DFF900007F3F000019
Mine:
:0857F000FFFFFF00FFFFFF00B7
:0857F800DFF900007F3F000013
So that's OK. I did a diff with winmerge on the v4 bootloader hex (available in the v4 download on the google code page) and your fail. The only differences are:
0xfffff NOP instead of 0x0000ff NOP at 0xa7fe (expected difference, not a problem)
Yours has:
:102D0000000009000000DF000000CB000000FB0015
:102D10000000FF000000F2000000DC000000A30043
:102D20000000DB0000008A000000FB0000009E00A5
:102D300000007B00000009000000E70000008700A1
:102D40000000D70000F7DF000000FB000000FF00DC
:102D50000000670000FFBB000000FF000000D7007C
:102D600000009E000000EB000000BF000000F70024
:102D70000000D90000008F0000007F000000C700A5
:102D80000000D80000008E000000FF000000FB00E3
:102D90000000E3000000DF000000B70000049B001B
:102DA0004000DB0000007B0000006F000000F80026
:102DB00000008D000000FB0000007D0000003100DD
:102DC0000000EB000000EB00000087000000F900AD
:102DD0000000FB00000069000000A6000000590090
:102DE0000000DF0000007F000000FF000000FA008C
:102DF00000049D004000BB00000000000000000037
But mine has NOP (error??)
Then from 0 to
:102FE0000000FE00FFFFFF00FFFFFF00FFFFFF00EC
You have the the updater which is erased on the next update.
There's no real way to tell the revision from the chip codes. You can write Microchip and ask about the date code, but it's easier to just connect with a programmer and it will be reported.
I have a very strong feeling it's a A3 errata issue we need to look at. I programmed an A3 chip directly with the bootloader and it won't connect. I'll read through the errata and see if I can get it going. I hope it will be pretty obvious.
[quote author="ian"]
I have a very strong feeling it's a A3 errata issue we need to look at. I programmed an A3 chip directly with the bootloader and it won't connect. I'll read through the errata and see if I can get it going. I hope it will be pretty obvious.
[/quote]
Mine with the problem is an A3/A4 chip...
Got it, issue 11 in the datasheet. Adjusting the value upwards 1 (from 0x21 to 0x22) fixes it with less than 3% speed error (was <2.5% error):
11. Module: UART
When the UART is in High-Speed mode, BRGH
(UxMODE<3>) is set; some optimal UxBRG
values can cause reception to fail.
Work around
Test UxBRG values in the application to find a
UxBRG value that works consistently for more
high-speed applications. The user should verify
that the UxBRG baud rate error does not exceed
the application limits. If possible, it is
recommended to use a comparable baud rate in
Low-Speed mode.
Edit: Bus Pirate main firmware also uses 0x22.
Shall we add a conditional check to the bl or use 0x22?
/me is glad for having rev b5 and no picprogrammer ;)
I've just finished verifying all versions at with the new speed settings, I'll release a new upgrade package in a minute.
0x22 is fine, it is the same speed used in the main Bus Pirate firmware, so it should work everywhere.
Here is the new update package:
http://code.google.com/p/the-bus-pirate ... ate.vb.zip (http://code.google.com/p/the-bus-pirate/downloads/detail?name=v2tov4-bootloader-update.vb.zip)
Here is a new package with full bootloader and firmware:
http://code.google.com/p/the-bus-pirate ... v4.0.a.zip (http://code.google.com/p/the-bus-pirate/downloads/detail?name=BusPirate.firmware.v4.0.a.zip)
What happened is this:
The ds30 Loader firmware calculated the UART baud rate using the equation from the datasheet. In some chips the optimal rate causes failure. The new baud rate is hard-coded, and taken from the Bus Pirate main firmware which was already adjusted for this error.
I have tested and verified the upgrade on A3/B4/B5 silicone and all seem to work now.
I also updated Sjaak's javascript converter to work in firefox. I had to add a buffer for the output because continuous writing to the text box crashed FF.
Ok Ian!
The alpha 0.2 corrects the problem for me also!
Edit: Mine is Rev 0x3003 (A3/A4).
Thanks,
Andrea
Good work finding the problem Ian!
Sjaak: "...But during flashing the app crashed (I think only the GUI, because the USB led was still flashing during the popup) I forgot the write down the error because i was scared. Second try it didn't crashed. I really like the app btw!"
The ds30 Loader GUI crashed during download? Did you have debug mode enabled? If so, do you know what was going on at the moment of the crash (unhandled exception)?
Did anyone else experience crash of the ds30 Loader GUI?
@mackey, i don't know when/how the error occured. :( I was a bit nervous when upgrading since i didn't have a pic programmer handy. And my first reaction was closing the error and thus closing the app. I must be in the GUI and not in the loader (two seperate threads I guess?) I remember seeing the error, but the USB led was still flashing. It happened around 30%
I guess I´ll be flashing some more in the near future so i´ll try to be more informational.
@ian: silicone? :P
Finally got around to upgrading my V2go.
worked like a charm, couple of things to note.
i used the updated firmware.
HiZ>i
Bus Pirate v3
Firmware v4.0
DEVID:0x0447 REVID:0x3003 (A3)
http://dangerousprototypes.com (http://dangerousprototypes.com)
Also the mode led seems to stay on during all parts of the upgrade and the only time it seemed to turn off was when i totally removed the program jumper at the end. not sure if this is a good thing or not.
I noted that once the new bootloader is loaded, having the jumper in either position will start the bootloader. im sure this is due to the reveresed pins of the v2go but i thought it was worth noting anyway
i used 115k at all times. now onto the v3
the V3 board went just as uneventfull. All ok.
I did notice that the mode led was flashing after the "upgrader" firmware ran. i may have missed that on the v2go.
the jumper works as expected on the v3. ie cover pgd and pgc it goes to bootloader mode. connect it between gnd and pgd. normal firmware as expected.
overall good job
edit: one thing that i would like to see is the ability to run the bootloader from normal mode. so i dont have to open the case to change the jumper setting. anyway its an idea
Thanks for the reports!
The LED should blink at the end.
Yes, the 'normal' jumper position on v2go now causes the bootloader to activate because the pins are swapped. I'll add a note in the upgrade guide. In the v2 bootloader it was dangerous to reverse the bootloaders like this because they actively drove the pin (don't want to short out the pin on every start), but now it's OK because it uses the internal pull-up instead.
After the upgrade, the bootloader can be activated at any time by putting a jumper between the pins, but that is only when the chip is blank, it won't happen after loading a firmware.
Good idea on jump to bootloader. I'll try to add that for the next release.
Hi Ian, hi all!
Just wanted to inform you that my Pirate is "saling again"! ;-)
I used the ICD2 to flash the last version of the v4 bl and afterwards ds30loader was able to upload the v4 firmware.
Thank you very much for your efforts!
If my spare times allows it, I'll give some feedback about the OpenOCD integration (in another thread) if I manage to get this running!
(This was the reason why I changed to v4 in the first place...)
BTW: My CPU revision was/is A3... (Surprise, surprise :-)
Salut, Jörg
@scorpia - I added the bootloader jump, it's command in the v4.1nightly:
http://code.google.com/p/the-bus-pirate ... /BPv3&v2go (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/firmware/v4-nightly/BPv3&v2go)
I added this instruction, as well as a define for the jump location in base.h:
asm volatile ("mov #BLJUMPADDRESS, w1 n" //bootloader location
"goto w1 n");
It's worked great for me so far. It just goto's the first bootloader instruction after the jumper check (0xa820). I don't know if it needs additional stack initialization or anything, but it works fine for me.
@Ian, I don't think the bootloader need an initialized stack. It uses all the register and I haven't seen pop/push instructions. I think you should also include the bootloader itself somewhere in the code??
How many bytes are now extra available for extra code? I can't wait to add my patches:P
About the pinout patch (if you want to add it) which trigger we should use?
I was just about to post in your improvements thread, let's move there. I'm ready to start patching a bit.
Sorry this is the only thread i can find :P
I noticed sometimes the loader resets the write program flag, so it is then not possible to write. I guess the save the bootloader sub erases it, but it is greyed out so even if you solve it (by altering the hex so the bL is safe) it stays disabled.
I altered the folowing line for now:
<WriteProgramAllow>true</WriteProgramAllow>
But is there a better way (perhaps a rewrite of the check)?
I also noticed if I enter the bl from the Buspirate it returns after sending an serial char, but if i enter it with the jumper (and remove it) this is not possible (ie it not jumps to the usermode program) It is working flawlessly for flashing but i think it should do the same way as entering it from the bp menu.
Thanks, here's the latest beta binaries with a fix for the problem described.
Too late mackey, I bricked my BP :D (I threw away the settings file and fucked it up :) ) The new binairies are on your site? I don't see them attached to your post.
Btw no more crashes with the loader, I think it was a coincidence
Oops, here it is http://mrmackey.no-ip.org/elektronik/ds ... ak/bin.zip (http://mrmackey.no-ip.org/elektronik/ds30loader/files/sjaak/bin.zip)
What exactly did you do? Should be pretty hard do corrupt the bootloader unless you download with the
incorrect custom bootloader placement.
That is exactly what I did :D
Although feeling a bit stupid now, but I was a bit frustrated back then, so i did something stupid I guess. I threw away the setting.xml and didn;t select the right bootloader. I made the adjustment I wrote about, but stil the setting was greyed (before i delete the settings file) then I got realy mad...
But I appreciate you made a patch for me ;)
I'll dump your Bus Pirate when I get it. What do you think caused it? The bootloader protects itself, and you got the bl protect error, so it didn't let you overwrite it.
The only thing I can think is that an incorrect jump instruction was written at 0x0000? If the program calculated the jump based on the incorrect bootloader location, and wrote it in the first page, then that would probably do it. It jumps to a random spot a page early and executes random code. I thought the page before the bootloader was blank, if so then it would just NOP it's way to the bootloader. Too bad.
Sounds like an important addition for the bootloader before deployment. It should check if the start address is 0x0000 and then insert the bootloader jump manually.
Lol, hope you loke the new gui Sjaak :)
Yeah thats what has probably happened. Here's a few thoughts:
* The gui doesn't erase pages that is not found in the hex file, option to add?
* settings.xml should be write protected?
* Don't let the gui start if settings.xml is absent?
* Let the bootloader set the 0x00 goto itself when it detects a write to row 0?
edit: I really like that expression, to NOP. Maybe it could be use irl also: "I was noping at work today" =)
I added this (not done, need to look up the ASM still):
;protect the jump instruction
;check if this is row 0
;row 0 ends at 0x3f
mov #0x003f, WCNT
cp WADDR, WCNT ;compare address and end of first row,
bra GTU, bladdrok ;if greater than unsigned, then OK
;insert the correct jump address
mov.b #0x04, [WBUFPTR] ;upper byte
mov.b #0xA8, [WBUFPTR++] ;low byte
mov.b #0x00, [WBUFPTR++] ;high byte
mov.b #0x00, [WBUFPTR++] ;upper byte
mov.b #0x00, [WBUFPTR++] ;low byte
mov.b #0x00, [WBUFPTR++] ;high byte
bra bladdrok ;continue below
I have two questions, I'll test to be sure:
1. Is the row write like an EEPROM? if a write starts at an offset address (0x01) does the last byte roll back to the beginning of the row (0x00)?
2. I need to sniff the bootloader traffic to see the format of the packet to know where to insert the correct instruction (protocol is byte 0 last?)?
#2 - nope, its first byte first:
ds30 Loader GUI IRP_MJ_WRITE VCP0 SUCCESS Length 198: 00 00 00 02 C1 04 00 A8 00 00 00 00 00 79 00 00 79 00 00 79 00
#1 - it looks like the write location is unpredictable if it's not on a row boundary. Writes starting to location 1 write to the second page, and appear to be pretty random in order.
Here's a new protection function I came up with, it hasn't been tested yet:
;check the end address
;write row size is fixed, any writes at (bootloader start-63) are an error
;if write end address (W0) is <= bl start address (WCNT) then OK
;= is ok because we don't DEC after adding, write 10 bytes to 10 = end at 19
bladdrchk:mov #BLCHECKST, WCNT ;last row write postion that won't overwrite the bootloader
cp WADDR, WCNT ;compare end address, does it overlap?
bra GTU, bladdrerror ;if greater unsigned then error
;protect the jump instruction
;check if this is row 0
;row 0 ends at 0x3f
mov #0x003f, WCNT
cp WADDR, WCNT ;compare address and end of first row,
bra GTU, ptrinit ;if greater than unsigned, then OK
;insert the correct jump address
mov #buffer, WBUFPTR
mov.b #0x04, W0
mov.b W0, [WBUFPTR++] ;upper byte
mov.b #0x00, W0
mov.b W0, [WBUFPTR++] ;low byte
mov.b #0xA8, W0
mov.b W0, [WBUFPTR++] ;high byte
mov.b #0x00, W0
mov.b W0, [WBUFPTR++] ;upper byte
mov.b #0x00, W0
mov.b W0, [WBUFPTR++] ;low byte
mov.b #0x00, W0
mov.b W0, [WBUFPTR++] ;high byte
bra ptrinit ;continue below
First, I got rid of the double bootloader overwrite check. If the first address is greater than the location of the next-to-last row, we should forbid the write. The old first check was just a less-restrictive version of that.
Second, if the write is anywhere in the first row, force the correct bootloader jump in the first instructions. The literal has to be moved to W before moving it to WBUF, as far as I can tell.
The comparison to anywhere in the first row is probably overkill, this would probably be better:
cp0 WADDR ;compare address to 0
bra NZ, ptrinit ;if not zero, then OK
I'm not entirely sure about that though.
Edit: it seems to work, but I had to preincrement the WBUFPTR.
Both the bootloader protection update and the jump instruction fix work in my tests. Great 'catch' Sjaak, but I'm sorry you had to brick your Bus Pirate to find this error.
Looks good. Here's a more generic version (maybe you switch to a bigger flash chip?).
You mean post increment? That makes sense.
#1 I believe the write will only occur in on the selected row even if you load the latches in another row.
mov.b #0x04, W0
mov.b W0, [WBUFPTR++] ;upper byte
mov.b #(0xff & STARTADDR), W0
mov.b W0, [WBUFPTR++] ;low byte
mov.b #(0xff & (STARTADDR>>8)), W0
mov.b W0, [WBUFPTR++] ;high byte
mov.b #0x00, W0
mov.b W0, [WBUFPTR++] ;upper byte
mov.b #(0xff & (STARTADDR>>16)), W0
mov.b W0, [WBUFPTR++] ;low byte
mov.b #0x00, W0
mov.b W0, [WBUFPTR++] ;high byte
Thanks! That was my next step, you beat me to it.
I'm going to add two variables to the end of the bootloader page before the final release:
1. A major and minor version byte so the main firmware can report the bootloader version.
2. The location the main firmware should jump to for bootloader entry (it's hard coded now).
I added a section at the end for interaction with the main firmware.
Instead of using a hard-coded address to enter the bootloader after the jumper check, this instruction at the last memory location will branch there according to the current compile.
Does anyone know how to position a raw value at an address too? I'm still working on that.
;------------------------------------------------------------------------------
; variables at the end of the bootloader page
;------------------------------------------------------------------------------
.section *, code, address(STARTADDR+(PAGESIZE*2)-6)
;blver: #0x0400 ;bootloader major and minor version
bljump: bra setup ;jump to bootloader after jumper check (for main program)
edit: I want the upgraded bootloader and a new/flashed bootloader to have a different version so it's easier to support without getting a full user history.
[quote author="ian"]
Both the bootloader protection update and the jump instruction fix work in my tests. Great 'catch' Sjaak, but I'm sorry you had to brick your Bus Pirate to find this error.
[/quote]
Hehehe. no problems ian. I'll send you the evidence :P Perhaps I should look for a cheap icd2 programmer (are those cheap china clones ok? i saw some for +-20 EUR on ebay)
I think (from the reactions I received from the bp) that the jump vector at 0x0000 is a GOTO 0xA000 (old location) which then NOPs to 0xA7FC where it encounters a GOTO _usrapp The user app is actually working (too bad it isn't bpv4.1 with the jump BL function in it (i now finally see the use for it!))
Lol, hope you loke the new gui Sjaak :)
Yeah thats what has probably happened. Here's a few thoughts:
* The gui doesn't erase pages that is not found in the hex file, option to add?
* settings.xml should be write protected?
* Don't let the gui start if settings.xml is absent?
* Let the bootloader set the 0x00 goto itself when it detects a write to row 0?
edit: I really like that expression, to NOP. Maybe it could be use irl also: "I was noping at work today" =)
I don't think erasing all the pages is a good idea (for the buspirate project it is but not adding value imho) since you can use unused flash for eeprom-emulation or storing some default (other bootloader if you are really paranoid :D) If it is userselectable it is ok I gues (but perhaps confusing).
isn't it I was nopping today? :P
for dynamic compiling a goto address could you use this:
;insert the correct jump address
mov #buffer, WBUFPTR
mov.b #0x04, W0
mov.b W0, [WBUFPTR++]
;upper byte
mov.b #0x00, W0
mov.b W0, [WBUFPTR++] ;low byte
mov.b #((STARTADDR&0xFF00)>>8), W0
mov.b W0, [WBUFPTR++] ;high byte
mov.b #(STARTADDR&0x00FF), W0
edit: like mackey said...
Or do I misunderstand you?
edit2: after reading your post again, don't you mean .db or .dw (byte and word)?
BTW your post before mine is your 666th
You're right, that's what Mackey suggested and I implemented it.
I also got the version located in the next-to-last location with:
;------------------------------------------------------------------------------
; variables at the end of the bootloader page
;------------------------------------------------------------------------------
.section *, code, address(STARTADDR+(PAGESIZE*2)-8)
blver: .word 0x0401 ;bootloader major and minor version
bljump: bra setup ;jump to bootloader after jumper check (for main program)
Just curious: why don't you ask mackey for a new version number to implement versioning?
it should be around http://code.google.com/p/the-bus-pirate ... ader.s#128 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/bootloader-v4/src/ds30loader.s#128)
It also messes runaway programs/bad flashes (like mine ;)) I can at least still run my last program :P (too bad it is a crap program!!). A better location (if you want to keep it) would be the bytes in front of the fuses.
I swapped the locations so the version is next to config bits and the branch to setup is before it. The information screen now shows the bootloader version. Old bootloaders will be 255.0 or something, so we can look for that and issue an upgrade warning. The new jump to bootloader method works great too.
I was just looking at the source and realized you meant something different then I first though... but the result is equal good. I thought you wanted it to place in front of the bootloader.. So my comment about runaway programs doesn't make sense.
Can we also add a jumper check at the end (around line 542)?
btss PORTB,#RB1
bra setup
This should reset the loader if the jumper is still in place after a receive timeout? However I didn't ever got till the timeout (could be an old version of the bootloader thought. I let the bl running for seconds and still the check bl function worked (I expected to exit the loader after 1ms) however it times out on a second attempt to check for BL.
Is the reaseon perhaps the read from uart is blocking?
The UART read has the time out. I'm not sure why it doesn't work, and I thought it was an error earlier. My best guess is that the auto-calculated value for 1ms is such that the timer rolls over first, or ????
The bittime for 115200 is 8.6 uS so it should be ok? Also it doesn't use the timer, right? It looks like a double loop that counts down, when both are zero it is an timeout.
What was the original value?
The original value was a few seconds.
Looking at the source of the bootloader, shouldn't the minimum time 29 ms? (otherwhise the bldelay=0 ?)
Yeah, I'm guessing that's what happens, and it DECs before evaluating, so it rolls over and the delay is really 65000 * 65000 (int*int)
With a comm timeout of 1ms you'll never be able to initiate a download unless you use a rtos. Why do you want that low timeout?
One user wanted fast start of user application at boot (<30ms), he modified the bl to have separate timeouts for startup and comm.
100ms is probably a good balance between reliability and waiting. Dont forget to lower the polltime in the gui.
Because we use a jumper or entry point for bl entry, I didn't want a timeout at all. When I started working with the firmware I set the timeout to 1 ms, and it stayed on for 10 minutes or so, so I left it that way. Works perfectly for our use as far as I can tell.
I like the idea of an timeout as Mackey sais. You need one when sending data.
I would say set it at around 100-500ms and a jumpercheck after so it jumps back to the very start (to retry the flashing in case of an comm-error/timeout. So when flashing goes bad you can retry as long as the buspirate is powered (or am I very very paranoid?) If flashing is done, remove the jumper and the userprogram (buspirate in our case) starts.
Ok, let's add a delay, then it can reconnect to the bootloader after a check for bootloader. This can go in a v4.3 bootloader. I guess that was my original intention with a 1ms delay - if no data, then restart and wait for more because we use a jumper and not a timer. I must admit I'm still not sure exactly what the stack pointer reset accomplishes at the end of the receive function.
I'd like to make a new version of the bootloader installer that works with the v4 bootloader to deliver future updates.
There has been a lot of user feedback now, and everything appears to be going smoothly. pppd has a Linux/Mac console that appears to work. I'd like to get a Windows port (or python script) eventually as well.
This was a fantastic effort, thanks again to everyone. I learned a lot about ASM and bootloaders/PIC flash memory. I've been porting this USB bootloader:
http://www.diolan.com/pic/bootloader.html (http://www.diolan.com/pic/bootloader.html)
to the USB IR Toy project for this month. The bootloader needed a lot of work because it used extended mode ASM, and extended mode is not supported in C compiler. I had to remove that and tweak it a lot. It was so easy to do with the ASM and bootloader experience I got working on this update.
No problem Ian. The upgrader can be easily extended to write other firmwares (i believe the flash subs are pic24f specific (mackey could tell more about this) feel free to use it in the usb toy or whatever. Perhaps add it to the buspirate firmware trunk (dunno the exact cost in bytes but the 0xFFFF shouldn't be included and the console functions are the same as the buspirate) Changing the linkscript should make it v4 bootloader compatible.
The stack pointer reset doesn;t do anything (i think) because there is no pop/push in the bootloader. There is also a stack reset in the beginning of the code..
Edit 1: fixed some typo's (pressed sent to soon, only to beat ian :P)
Edit 2: I noticed you already add the test for jumper at the end, but the timeout is still near infinity (1 ms). We shluld change this in the settings.inc to lets say 30. Also change the ds30loader the following (or simular):
.if BLDELAY<1
.error "delay should be at least 30ms@16Mhz !!"
.endif
I was wonder if it was worth adding a small option to the v4 bootloader to make it respond to a keystroke from within a terminal program.
That way if you are in a terminal program and you hit say enter. it could come back with a small message saying its in bootloader mode or something similar. it could make some peoples upgrade issues easier to diagnose.
scorpia i like the idea, it can be added as a check if the first char received is a space (for example) display a small message. There is plenty of space available in the bootloader
I like it too, it causes lots of confusion.
Feelling a bit boring (not want to work today..)
add line @132:
.equ HELP, '?'
add lines @165:
.if BLDELAY<1
.error "delay should be at least 30ms@16Mhz !!"
.endif
add lines @309:
rcall Receive
mov.b #HELP, W8 ;; use w8 as temp
cp.b W8, W0
bra eq, waithello
SendL 'B'
SendL 'L'
SendL '4'
SendL '+'
SendL #0x0a
SendL #0xad
bra exit
replace the old line @309
waithello: rcall Receive
It should returns 'BL4+rn' when the first received char is a question mark. As always with my code no warranties!!
Register W8 (unused) is destroyed, but we could also use WCRC (gets cleared after the hello check)
Maybe we can add this as a response to the incorrect hello character? That way it says bootloader on any key press?
;------------------------------------------------------------------------------
; Receive hello
;------------------------------------------------------------------------------
rcall Receive
sub #HELLO, W0 ;check
bra nz, exit ; prompt
Before branch to exit, it could say 'BOOTLOADER' if the hello character isn't a match? Would this happen on every timeout too? Might take a modification to the timeout routine.
the timeout is in the receive sub so it should ok. it only displays when receiving a bad char.
Would you like to branch the current bootloader and add this and the delay to v4.4?
I think it's a good idea to keep upgrades as odd releases, and full installs as even. Any thoughts?
Most of the things I wrote stay at v0.1 premature alpha until now. About versionnumbering I'm fond of the way the linux kernel does the version numbering (especially having major and minor). odd is experimental and even stable, you mean?
No, I mean different version numbers for a bootloader that was installed with the upgrade, and one that is installed with a PIC programmer. For example the v2 to v4 upgrade gives version 4.1, the bootloader in the firmware download shows v4.2. Both are the same, it just helps with support if I know at a glance how the user got the v4 bootloader.
I've done some rearranging of the bootloader-v4 folder in SVN:
http://code.google.com/p/the-bus-pirate ... tloader-v4 (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/bootloader-v4)
I split the firmware into the old version (v4.1) and the new version (v4.3). I added the delay warning to v4.3, and increased the timeout to 500ms. I was adding the bootloader printout, but I'm curious: what is the best way to do it? Right now it exits and branches to the user program if the hello is wrong. Do we want it to test the jumper and keep listening if the hello is wrong?
I also split the updater/installer to a v2 to v4 and a v4 to v4. The new one is to install future versions on existing v4 bootloader installs. I removed the reserved memory location and added the v4 bootloader linker script.
One thing to consider if we institute the delay: we'll need an additional variable that tells the bootloader when we jump from the main program. It should have the same function as the jumper check at the end. Otherwise the user will only have a half-second to connect after typing $ in the terminal.
Good thinking. An other entry point for the buspirate can solve this, which sets a different timeout. I prefer this over emulating a jumper.
The current entry method is goto the next-to-last instruction, which is a branch to setup, right after the jumper check.
It seems like we'll need a new variable either way. The current timeout is a constant that's loaded in the receive loop. We'd need to change that to another variable and set it on the entry point.
Here's my example. It flags WFWJUMP where the user jumps in, then WFWJUMP is also tested like the jumper when the RX times out.
Index: ds30loader.s
===================================================================
--- ds30loader.s (revision 282)
+++ ds30loader.s (working copy)
@@ -72,7 +72,7 @@
.equ WADDR, W5 ;memory pointer
.equ PPSTEMP1, W6 ;used to restore pps register
.equ PPSTEMP2, W7 ;used to restore pps register
- ;.equ UNUSED, W8 ;
+ .equ WFWJUMP, W8 ;did we jump here from the firmware?
;.equ UNUSED, W9 ;
.equ WDEL1, W10 ;delay outer
.equ WDEL2, W11 ;delay inner
@@ -193,7 +193,7 @@
; variables at the end of the bootloader page
;------------------------------------------------------------------------------
.section *, code, address(STARTADDR+(PAGESIZE*2)-8)
-bljump: bra setup ;jump to bootloader after jumper check (for main program)
+bljump: bra firmwarejump ;main program jump here to access bootloader
blver: .word BLVERSION ;bootloader major and minor version
@@ -238,6 +238,8 @@
;check for jumper
btsc PORTB,#RB1 ;skip next instruction if RB1=0 (jumper)
bra quit ;branch to the user application if RB1=0
+
+ clr WFWJUMP ;we came from jumper and reset, not firmware jump
;----------------------------------------------------------------------
; UART pps config
@@ -299,6 +301,7 @@
;------------------------------------------------------------------------------
clr DOERASE
+
;UART
mov #UARTBR, W0 ;set
mov W0, UBRG ; baudrate
@@ -542,7 +545,10 @@
bra nz, rpt1
; If we get here, uart receive timed out
mov #__SP_init, WSTPTR ;reinitialize the Stack Pointer
- btss PORTB,#RB1
+
+ btsc WFWJUMP,#0x00 ;if we timed out and came from firmware, go to setup
+ bra setup
+ btss PORTB,#RB1;if we time out and jumper still attached, go to setup
bra setup
;------------------------------------------------------------------------------
@@ -586,8 +592,14 @@
;------------------------------------------------------------------------------
bra usrapp
-
;------------------------------------------------------------------------------
+; firmware jump entry point (kind of like a function because it's never reached from the above code
+;------------------------------------------------------------------------------
+firmwarejump:
+ mov #0xffff, WFWJUMP ;flag that we jumped from firmware
+ bra setup ;jump to just after jumper check
+
+;------------------------------------------------------------------------------
; End of code
;------------------------------------------------------------------------------
.end
I think the last steps could be even easier:
btsc WFWJUMP,#0x00 ; skip next if bit0 is 0 (=not jumped from bp)
btss PORTB,#RB1 ; skip next if RB1 is 1
bra setup
Not that there isn't any room left :P
Good call. I sat and stared and thought there had to be an easier way, but I'm not that ASM savvy yet :)
hehe, did you try it and did it work? (it was all from the top of my head ;) was a terrible day at work :D)
The v4.3 branch is totally untested. I'll try it, and the v4 to v4 updater, hopefully tomorrow. A couple PCBs came in (Bus Pirate PIC programming adapter and logic analyzer) and I've been busy soldering and writing firmware for them.
OK, no need to hurry ;) It's afterall friday ;)
Will those be commercial (or through seeed) available?
Yeah, they're all future projects. I tested the high-voltage programming adapter yesterday and it works as expected. If anyone wants to help with the PIC programming port (PC or micro side) I'd be happy to send a PCB and/or (partial) kit (with the parts I have).
I did check in a new version of the BL installer.
changes:
- universal binary (should work with old and new BL)
- displays current and packaged bootloader version
- changed the text and comments a bit (serial comma joke deleted)
- debug mode (if still needed) is controlled by the release/debug setting in the IDE
- modeled is more consistant for error checking (led is of, and blinks after the upgrade)
screenshot of debug build:
Universal DS30 Loader installer v0.3 (C)hris 2010
Released under Creative Commons null license.
RUNNING IN DEBUG MODE!!!!
Found bootloader v4.1
Will install bootloader v4.1
Type 'Yes' to program the new bootloader.
Disconnect power if unsure (no harm done).
yes
Erasing 0x8C00... done
Erasing 0x9000... done
Writing row 0 1 2 3 4 5 6 7 done
Success!
Upload new firmware with the ds30 Loader app to complete the upgrade.
Great work.
I like the auto identification of the version. Will it work for v2? Maybe check if oxffff and say 'probably v2'.
With the v2 bootloader the user reset vector is located at 0xc04, it was declared in the v3 firmware as:
unsigned int userReset __attribute__ ((space(prog),section(".init"))) = 0xC04 ;
unsigned char timeout __attribute__ ((space(prog),section(".init"))) = 0x00 ;
This isn't in the universal updater, but isn't in the v2 to v4 updater either. I know that P24QP.exe relocated the 0x0000 jump instruction to the user location, and I think that's hard coded as 0xc04 in the v2 bootloader and P24QP.ini config file. I think this might be a minor bug in the v2 to v4 bootloader, but I'm unsure of the impact.
I don't have a v2 anymore :P but I gues it is 0xFFFF at that location. So the version would something like 255.255. I can add a new check no problem. If it is 0xFFFF I'll make the message 'pre-4'
Where was that declared? I think the p24Qp program does simular things as the new ds30loader (regarding the startup of the payload and modifying memory locations)'
[s:]edit: isn't that to reset the app without starting the bootloader?[/s:]
Edit2: I found it in the source, by looking at it and compiling/examining the old v3.6. I would say it is for the bootloader to know what the timeout is and where to jump when the bootloader is finished. (see also page 2 from http://ww1.microchip.com/downloads/en/A ... 01157a.pdf (http://ww1.microchip.com/downloads/en/AppNotes/01157a.pdf) ) Strange the old updater did work correctly.. I also see (in the linkerscript) some mentioning about storing it in a location at 0x0100. Very confusing :S
I do see some things in the linkscript but they don't write the correct value there, I assume the program did write them in flash to be safe. I'll [s:]adapt the linkerscript and[/s:] add the relevant things to main.c
Added the changes to svn.
Although I don't think it is necessary to reserve 2 programwords as I think the old bootloader stores it elsewhere. But better safe then sorry!
Here's the words from a dump of a complete v3.2 firmware+bootloader that I sent Seeed:
:100C000004E8B7000040EB0005E8B7001E40900084
I'll look a bit closer and compare to a dump of the loaded updater later to see what's going on.
As you noted, the delay is at c00 (not used, I stripped that code from v2 bootloader) and the jump instruction location is at 0xc04. Like ds30 Loader, the old app read the jump location at 0x0000 and moved it to c04 when flashing. When the updater is loaded, p24qp must write the jump location to 0xc04(?) It seems like that would mess up the updater? I'll do a dump for us to look at to be sure.
We probably don't need to include the variables. Can we just increment the start location in the linker by two words?
Complete dump from a chip with v2 bootloader v3.2 firmware is attached to this post.
Sorry, here's the good dump. This is 0xc00 from the bootloader updater before bootloading:
:101800000F802000007F22000001880000000000FF
Here's the line after I bootloaded it then dumped the chip:
:10180000000C0000FFFFFF00000188000000000046
if you look at p24qp.ini, the last lines tell it where to relocate the values:
userresetvector="C00"
bootdelay="C02"
So the p24qp programmer IS overwriting the first two instructions of the updater. The reset instruction and an instruction that loads a value into W. They are both interpreted as NOP, so it walks it's way to the correct code although without reset, and without the correct value (0x27f0) in W0 before mov.w'ing it 0x0020.
Attached are two screenshots of the dissassembly. Also, a .zip with the original upgrader hex and the dump after bootloading it onto the chip.
I'm going to test the 'universal' bootloader upgrader now and release an update to the upgrade package. I'm not sure the impact of this bug, but it's clearly overwriting two instructions.
Ok, I made some changes to the universal updater (v4 to v4). It needs to have the config words for a v2 upgrade in case the user is using the p24qp.py upgrade script that erases the whole chip and requires the config words.
It seems to work well. Attached is a screenshot of the universal updater (now determines current BL version), a screenshot of the disassembly of a chip dump (looks good) and a .zip with an exported chip dump.
I uploaded the new upgrader to firmware/v2tov4upgrader/, after some testing I'll release a new upgrade package.
Good work. ( shouldn't the files in the upgraderv2tov4 also be updated? or are we moving towards an universl binary?)
My analyse of the impact:
The move #0x800, W15 is to setup the stack pointer (which is probably also done by the bootloader) The program doesn't use the stack very much, so it isn't a very big problem (still a problem though). the other one is setting 0x27f0 to the stackpointer limit register which shouldn't be much of a problem either when not using the stack very much. But glad we slashed this bug also :P
To bad the fuses are need to be set, since the new bootloader won't program the .hex if you try to alter 'safe' locations (or is there a setting in defaultsettings.xml that adresses this ?)
Off topic: that programmer does it fit on top of the bp or do you need to have a cable for it? I like it (more) when it is stackable, just a thought
I just used the new one for the universal binary.
It would be nice to have a setting in ds30 Loader to ignore the bootloader region, like the old programmer.
The programmer board could stack, it uses the same pin connection. Just put a female header on the bottom instead of a male header on the top. It would go out from the front though, instead of back over the Bus Pirate PCB. It would have been a good idea to make it stackable, but I didn't think about it. I didn't do a great job designing these PCBs at all, they'll need a second revision.
Like the "Allow overwrite of bootloader" checkbox?
Yes, but it would need to ignore the section because the bootloader will send bootloader protection error for operations in that region. Are BL overwrite errors already ignored when allow overwrite is checked?
Hmm, you mean the download should continue when allow is checked and bl protections is received?
I think ideally, a separate setting that strips any code from the calculated bootloader page. The problem is that we need to include config bits for the v2 bootloader, but v4 bootloader (correctly) sees it as overwriting the bootloader. For a 'universal binary' we'd need a way for ds30 Loader to deal with this extra code. Ideally not sending it at all (notice in box: "stripped code from bootloader region"), but possibly ignoring all errors (verify and bl protection).
I made a small change to the v4.3 bootloader - a bad hello now branches to the jumper/variable check at the end of receive before exiting. We can now add Sjaaks' function to print 'BOOTLOADER' if the user is watching the terminal.
I'm going to look at adding a verify check to the updater. I've seen some strange corner cases. Maybe we could catch them with a verify?
Were those caused by a bad flash? Is it on a special location or just random?
One thing I could think of are interrupts (which should be disabled during writing) The code hasn't one AFAIK, but perhaps it is enabled somewhere (perhaps old bootloader)??
from the memory manual:
; PUSH SR ; Disable interrupts, if enabled
MOV #0x00E0,W0
IOR SR
...
...
POP SR
During testing the newterm branch, I ran again into the problem the write program flag is unchecked. after that it can't be set. although I solve the isssue that causes it to uncheck (write fuses). removing those files are a bad idea (see older post of me bricking my BP)
Can it be made so it ignores it or recheck the option after it is solved? I can solve to get the settings.xml from svn and removing the recentfileX.xml.
Also an other point of improvement: Add a rescan comports option, as the BP needs to be connected at startup, if plugged in after the program has started it fails to see that com-poort. (if it has found it before it is selectable, it only fails the first time)
@ian, you already got some extra info about those cornercases?
The corner cases are random. I'm never sure what to make of them - user error, computer error, Bus Pirate defect. There haven't been any major problems though. I haven't received a single Bus Pirate to reflash after an 'official' v4 upgrade. I don't count yours :)
A new bootloader v4.3/v4.4 compile is in the SVN:
http://code.google.com/p/the-bus-pirate ... /BPv3&v2go (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/firmware/v4-nightly/BPv3&v2go)
Includes these changes:
*0.5s timeout (can now check for bootloader then download without reset, not one-shot only)
*added jumper test - if jumper, don't exit on 0.5s timeout
*added jump entry variable - if jump entry from firmware, don't exit on 0.5s timeout
*bad hello (space, enter, etc) prints 'BL4+' in the terminal and resets (can connect and upload after trigger, tested)
*v4.3 (upgrader) v4.4 (programmed with a PIC programmer)
I have not made an upgrader yet. I'll test it for a while and probably release it with the next firmware update. Any comments? Testers welcome.
Nice work!
I think it is fairly complete by now. If it is safe I'll test it for you.
How do you exit from the bootloader if you jumped from the buspirate?
I think it's fine for a test.
A hard reset is the only way out, but that's a good idea anyways to make sure everything is in the reset state.
Ok fine with me. A hard reset is a good idea indeed.
But I'm gonna mis placing my little red jumper I guess ;)
Does the loader (hostside) accept .hex files which don't sets a proper jump to the jump userprog? And can I afterward program a normal firmware? Prefferable in just one run (ie without reseting).
I want to program an .hex (which contains data for the firmware) and program the firmware afterwards. I know how to combine these two by copy and paste in a textfile, but this requires a lot of manual steps...
(i'm still a bit scared to try it with the chance of bricking my bp)
The loader will accept these files, but the bootloader always programs the correct jump instruction. As long as there's no data on the same pages, I believe they will be left alone and not erased.
Also if there is no entrypoint? I did got an error on this.
I just make a small jump to the bootloader to be sure ;)
Not sure if this is the right place, but I have been getting frustrated with the current scheme of things. If I try to use pirate-loader, which I prefer since it works on all my platforms, I find that I end up having to jumper the board into boot mode because it falls out way to easily. If, using newterm, I try to go into boot loader with $ then I get out, and start the loader with a --hello, I get a successful connection, but it drops out of the boot loader so I have to go through the same dance again? It seems to me that the --hello should not exit the loader. As a result the only way that seems to give me any success is to jumper the board, but each time I do that I start missing the arduino with a hardware reset circuit so that I can reset and download automatically. Now I understand some of the arguments pro and con there, but the pain level I am finding is higher than I think it needs to be. So I am asking a question to see, am I doing something wrong? Is there an update I missed? Or am I just dazed and confused?
the --hello step is unnecessary. If the mode light is on you can flash rightaway. Someone else made a patch for pirateloader that send the $ first (without a y (newtem specific)). You could extend that.
Personally i like the jumpering as it is a manual thing. Also the 'arduino' is imho not simular/comparable with the buspirate: the buspirate is a developmenttool and the arduino is a development platform.
I understand, I am just spoiled by the dev platforms that allow remote reset and bootloading. I have had so many issues with the drivers and connections, I find I have to test it first. Maybe I can learn to read the lights better. I guess I will give that a try.
Hi rhyde - there is an updated version of the bootloader in the SVN that allows multiple connects, and leaves the bootloader automatically (if a jumper was used, but not if you jump with $). I haven't put it into an installer yet, but if you have a PIC programmer you can program it directly.
The only pic installer i have is a pic-el board I did years ago, and i don't think that would work.