Boot loader working and why

[Hans Wedemeyer]

Some points I learned along the way to making a bootloader.

I started with theByteFactory bootloader becasue it was in C and I had space for it. I then replaced the communication code with my version based very loosely on the CCS loader.c .
A note about loader.c it's a good starting point, but some things are in the wrong order. There is no error checking and it needs a lot of work. I think I ended up with about 5 of the original lines of code... !

I added dedicated protocol to allow re-sending is a line of the hex file if it did not come across as it should have. As the serial connection is by wireless (blue teeth) there is a possibility of losing a connection or getting corrupted reception.

I changed the way data is written and simply write a block (lines worth of the hex file) at a time.
Take Note:
Make sure when writing less than getenv("FLASH_WRITE_SIZE") that you do this : read a block of getenv("FLASH_WRITE_SIZE") size / then modify the read data with the data you need to write / and then write back the entire block.

Also take care of statements at the end of the hex file.
I'm using the PIC18F6720 one of the early Erratas said to insert two 0XFF and move the reset vector up two bytes. That complicated things. take care when reaching the end of the hex file you may find instruction to write FF's at address zero... ! Be careful not to clobber the first few bytes, this was an early mistake. !

Finally the reason it now works:
Between the bootloader reset vector and the application vector there should be FFs and after the interrupt vectors there should be 00's.

It's not enough to re-create the vector values you must re-create the the rest of the first few bytes exactly as they originally were in the application hex file.

All this is complicated by the fact that some chips have a getenv("FLASH_ERASE_SIZE"); size greater than the getenv("FLASH_WRITE_SIZE"); size so that has to be taken into account.
It's described in the CCS help for write_program_eeprom()

Performance could be improved a little but loading 120K of code via a bootloader takes time. If I increase the block write to 64 bytes it may take less time. The slow down is not having interrupt driven comms.. in the bootloader. so small delay between bytes that are sent by the PC is needed to avoid data loss.

Once again thanks to everyone for the help.

[libor]

Thank you, Hans, for sharing us your experience, let me add some thoughts. I have also written a bootloader based on theByteFactory's into a 18F25J10.
The speciality of this chip is the 1024 bytes of erase block size and 64 bytes of write block size. and a RAM size of only 1024 bytes. So in lack of RAM I did not have the possibility to read a block into RAM, modify it and write it back. So I came to an assumption that a .hex file defines data in a sequence of strictly increasing memory addresses. So I do not read the erase-block, just write them in sequence. (you might get a speed increase doing so, with the caveat of never having a hex file jumping back-and-forth in memory addresses)

Re: delay between characters. I use a buffer that stores one line of a hex file with no extra operations required between the arriving bytes in the same line. Lines are getting processed only after CR has arrived. So a delay (I use 10ms) only after each line and no (or a very short) delay between the characters is OK for me. (this would mean a speed increase for you also, I think)

[Guest]