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? )
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.
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!)
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, 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).
Hardware2.5 is the BP v2.go and hardware3 is the latest version. They share the same source code and hardware (chipwise). The only difference is AFAIK the I/O pin placement. More details on http://dangerousprototypes.com/bus-pirate-manual/
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).
[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)
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 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):
erase:and#0xF800, WADDR3 sub#0xA800, WADDR3 braz, prot; if true protect it branprot prot:clrDOERASE; clear DOERASE flag, just to be sure braMain; fail silently nprot:btssDOERASE, #0
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*
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..