• Locked Locked
  • Replies 8 replies
  • Subscribers 80 subscribers
  • Views 3975 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP Firmware Updates Over SPI

Kris
Prodigy 245 points

Hi everyone,

After implementing a relatively complex program on an MSP over the past year, and with tons of reading on the forum, I've decided to hopefully contribute back by writing a small technical paper. With IoT becoming such a big thing now, it's inevitable that firmware updates will be required for functionality additions and security patches, and one of the projects I had to do was implement an update mechanism for the MSP firmware (which includes firmware for a Bluetooth controller). We were relatively naive in the beginning of the project, and didn't build in any functionality for BSL updates, however I was able to successfully get the MSP to update itself when data is sent via the SPI bus from a separate controller (a higher power System On Chip). This is was a bit complicated and took much reading of the forums and technical documents to know what I was doing. Hopefully this paper summarizes some key aspects, and one day I hope to be able to put the project, or at least parts of it, in a Git repository.

Please reply if you have questions, comments, or would like to help me edit it for future publications.

Thanks

Kris

msp.pdf

  • TI__Guru**** 202096 points
    Hi Kris,

    Thank you for sharing your solution with us! It is always great to see this kind of community involvement occurring on the E2E forum. For anyone else stumbling upon this thread, I'd like to reinforce TI's current BSL and OTA solutions:

    OTA Updates with the MSP430FR57xx and CC1111 USB Dongle (SLAA511): www.ti.com/.../slaa511a.pdf
    MSP430 Programming With BSL (SLAU319): www.ti.com/.../slau319k.pdf
    MSPBoot (SLAA600): www.ti.com.cn/.../slaa600a.pdf

    More OTA solutions are planned for release on MSP430 devices by the end of 2016.

    Regards,
    Ryan
  • Guru 74080 points
    Hi Kris!

    Thank you very much for sharing your documentation!

    Dennis
  • Mastermind 8905 points
    Thanks for sharing. You did a great job.

    I have some questions for you.

    (1) You mention "route SPI clock to an interrupt pin". This should be a good idea to save one pin. My idea is to share SPI_CSn pin as interrupt to MSP430. at the beginning, MPS430.SPI is not enabled. The SPI_CSn input pin is configured as input and interrupt enabled (depends on MSP430 models, this may not be possible). To upgrade, SoC send a dummy byte to MSP430. SPI_CSn will be pulled low. This will cause the interrupt to be triggered. Then, MSP430 initialises SPI slave interface...

    (2) You choose TXT format. My question is why not using binary format? TXT file size is much larger and required more time to transmit. If binary format is used then I2C interface could be a better choice since it only uses two pins. Small MSP430 doesn't have too much pinouts and most sensors come with I2C interface. There is a big chance that MPS430 needs to enable I2C interface. CCS can generate binary output directly in the post-build step. It should be very convenient for users.
  • in reply to Robert Chen
    Prodigy 245 points

    Thanks Robert for the vote of confidence.

    1. Yes, when I first was using the MSPEXP5438 board I routed the CLK to the interrupt as to trigger the SPI setup. Definitely the CS could work too, it just depends if the peripheral has pins on an interruptable port, as you mentioned. For me P1 and P2 on the 5438.

    2. Good question, and absolutely using a binary file may save some time for parsing on the SoC side, but the # of bytes transmitted over SPI remains the same, since I'm not sending spaces, newlines, etc. There are some performance enhancements in my design that could be made however, and I namely did this to ensure stability in the first release.

    a. Erasing: since erasing on 512B boundaries needs to happen, it is important to keep writes aligned, otherwise you'll knock out previous data you just wrote. So for simplicity, I pad all empty space with 0xFF, and keep a consistent 512B aligned erase/write cycle. To save time, a command of Erase @ offset X could be used, instead of sending so many 0xFF bytes, however I do a check for each chunk on the MSP side, and if it only contains 0xFF, then I skip any write (but the transmit of that data is still done via SPI). One thing I wasn't sure of is erasing old data/instruction memory needs to happen when a new program is written into flash, or if those segments can remain, I took the assumption that everything should be erased.

    b. Writes: I only write one byte at a time, I can easily enhance performance by writing words or long-words

    Hope that provides additional clarification.

    Kris

  • in reply to Kris
    Guru 33653 points

    Kris said:

    b. Writes: I only write one byte at a time, I can easily enhance performance by writing words or long-words

    Block write can be executed from RAM (your algorithm is working with blocks anyway) with 100 KByte/s, or with SMART bit enabled over 200 KByte/s. Faster writing, shorter VPP on state, lower consumption.

    http://forum.43oh.com/topic/2972-sbw-msp430f550x-based-programmer/?p=48762

  • in reply to zrno soli
    Prodigy 245 points
    Good to know, thanks!
  • in reply to Kris
    Mastermind 8905 points
    For question 2, I don't understand why the number of transmitted bytes will be the same? Can you give me an example?
  • in reply to Robert Chen
    Prodigy 245 points
    Following the outline here: processors.wiki.ti.com/.../Generating_and_Loading_MSP430_Binary_Files, I programmatically parse the TI-TXT file which is burned into the SoC, and turn this into binary data. This is the data that is then sent over SPI. In terms of actual wireless transmission, this is completely separate and fully handled on the SoC, and doesn't fit into the MSP example I created.

    I also tried the block write mechanism, and now see > 30% reduction in update time.

**Attention** This is a public forum