N. Coesel wrote:
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.
unfortunately, does the msp430 not support locking. (at least not the
1xx series. the 2xx have some locking, but only for the information
memory and it seems, only 64 bytes..)
i think the best protection is if you have a large enough capacitor on
the supply (best before the voltage regualtor).
before every activation of the flash controller, check the voltage and
decide if there is enough energy to complete the operation.
some other measures are:
- keep the flash cotroller activated as short as possible. disable it
between writes.
- use MCLK of 1..2MHZ during the update. that way you're always within
the specs if VCC drops. (reduces the chances of random code execution)
- use a reset device, a msp430 with brownout or svs.
- the 2xx devices will have beter protection against random code
execution
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.
as i mentioned in the other mail, i'm working on a simiar loader.
i've made two special linker scripts:
- one for the updater that only uses the top 2kB of the flash
- the other for the application, which cuts away the top 2kB flash and
moves the interrupt vectors 2kB lower
then i can mass erase, program the boot laoder and then the application
trough JTAG.
the updater redirects all interrupt vectors to the applications
interrupt table.
i identified 3 possible use cases:
- normal upgrade. the application can initiate the upgrade
- no application. the boot loader "sees" the invalid application reset
vector and falls into "upgrade mode"
- a completly wrong application has been progarmmed. the boot loader
needs to check some key combination or something after a reset to
force "upgrade mode" before launching a corrupt application.
unfortunately there is one problem left...
when the updater is erasing or writing a flash segment and the power
fails. then in rare cases it could lead to random code execution and
with a bit of bad luck destroy the boot loader itself.
chris
