This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Software Update From SPI Flash Memory

Other Parts Discussed in Thread: MSP430FR5729, MSP430L092

Hi,

First post here.  I am using an MSP430FR5729 in a Bluetooth Low Energy application.

The MSP430 needs to receive over the air updates over Bluetooth.  The program is too large to have two copies in the MSP430 RAM, but there is a large external SPI flash memory chip that can be written to.  Here's how I see it working:

  1. Program is transferred over the air to the MSP430, which buffers and stores it in the flash memory in a dedicated location (with verification, CRC, etc.)
  2. MSP430 is rebooted
  3. On reboot, check memory location for a newer software version.  If present, start update.
  4. A small boot loader subroutine runs that extracts the new software and overwrites the MSP430 program memory (without overwriting the boot loader).

The last step is the one I'm struggling with trying to figure our what the implementation looks like.  The MSP430 has a bootstrap loader but I don't think this is what it's for.  I don't have any experience doing software updates in this fashion so I really could use some advice!

  • Zack Nienstedt said:
    The MSP430 has a bootstrap loader but I don't think this is what it's for.

    Only on the MSP430L092, which has no flash but only ram and loads its firmware form an external rom at power-on.

    if you dig around in the forum, you'll find several threads discussing the kind of bootloader you need. Yes, it must not overwrite itself, but it also must not update the interrupt vector table. So so a method of interrupt forwarding is required. Also discussed in those old threads.

  • The proof of the pudding is in its eating.

    Your outline is fine. Many have tried similar schemes with various degree of success. This include many TI "FET-tools". They too occasional kill themselves during "firmware update".

  • Zack,

    I am about to start working on an almost identical project. Were you able to successfully implement your described bootloader? Any hints/tips?

    Thanks!

  • Good news and bad news:

    The Good: yes, we successfully implemented it and it worked great.

    The Bad: another developer took over this project, I was just scouting it out.  So I can't really share any implementation details.  I remember a couple of the trickier bits along the way.  One was managing the pointer to the interrupt vector table, which needs to be handled correctly as it changes when the bootloader hands off to the main program.  The other was figuring out how to combine the two programs (which we implemented as two separate projects in CCS) into a single hex file.  For this I think we actually ended up using a Python script to manipulate the two hex files after they were created to fit them into the memory map.  The older threads that were mentioned above were also helpful.

    Abstracted from all of that, there are the common problems that come along with this type of approach.  You need a robust way to version the code to allow the bootloader to correctly identify new versions.  Also useful is a method for performing a factory reset to recover from bad updates that otherwise may brick the device in the field.

    Sorry I can't give you more specifics.  Good luck!

  • Not a problem! Thank you for the hints and pointers, I really appreciate it.

  • I wrote few bootloaders in my live,

    it could help you,

    http://www.ti.com/lit/an/slaa600a/slaa600a.pdf

**Attention** This is a public forum