At 17:05 17-06-05 -0400, you wrote: >N. Coesel wrote: >> At 04:53 17-06-05 -0400, you wrote: >> >>>I'm trying to write a bootstrap routine in C that will reside in flash >>>and be copied to RAM for execution. Can anyone give me some helpful >>>hints on how to do that? >> >> >> In an earlier discussion the method of copying a routine was discussed. > >That should be the easy part. I wasn't worried about that, but I'll >check the archives just in case I'm missing something. > >>>I've searched the docs for any reference to relocatable code (there will >>>be some subroutines, also in RAM) or preprocessor commands that might be >>>able to specify that this code will be running at a particular address >>>(in this case within the RAM) and haven't been able to find anything >>>that relates to this problem. >> >> >> Why would you copy more than one subroutine in RAM? The only thing you will >> want in RAM is the code that actually programs the flash. The amount of >> memory doesn't allow for allocating large fixed buffers for this. > >This BSL also needs to decrypt the data to be written to flash and >handle some handshaking with the PC. The decryption routine might be >erased at some point during the flash programming even if I only erase >the segment about to be written. That wouldn't be good. And, part of >the decryption algorhythm makes multiple calls to a subroutine, so that >inlining that code would increase the size - this might not be a >problem. I'm using an msp430x449 with 2k of RAM, so I think I'll have >plenty of space for code and a communications buffer.
I'm working along similar lines. I think it is a very bad idea to allow to erase the decryption routine. If power fails during programming, or the file to be programmed is invalid, the device is ready for a repair because the end user is unable to load new firmware. It is also a good idea to add extra guards just before the flash erase process is started which explicitly protect the sector(s) containing the download & decryption routines. If the software starts to have a life on its own (random execution), this will help to prevent unwanted erases of critical information. In my setup, the bootloader will be fixed (like the standard BSL). It will program the rest of the flash memory with an overlay which is the actual firmware. My bootloader will never be replaced and should also be intelligent enough to talk to a host in order to obtain a new file for programming. This will -hopefully- result in a device which can always be reprogrammed by the end user unless it is really broken. Nico Coesel
