Field Update of system firmware - Flash updater via UART

Dlo, 

The BSL information for MSP430 is located here: http://processors.wiki.ti.com/index.php/BSL_(MSP430)

Damian 

Thanks Damian!

I should have been more detailed about the request. I'm looking to upgrade the code via UART, but the data is coming in from a WiFi module communicating to the MSP430 via UART.

Thank you.

Hi Dlo,

The MSP430F5xx has a Flash BSL which can be customized according to your needs. 

Usually, the BSL works via UART for non-USB devices or USB for USB-devices. SLAU319 (http://www.ti.com/lit/ug/slau319d/slau319d.pdf) has a good description of how this default BSL works, including a description of all commands.

The USB BSL is explained in more detail here: http://www.ti.com/lit/an/slaa452b/slaa452b.pdf

If you could get the exact same data via WiFi-UART, then in theory, you could use the same UART BSL in your application. However, if you need additional steps (i.e. initialize the WiFi, different packet format, etc), then you need to customize the BSL. 

In order to achieve this, the best document is SLAA450 (http://www.ti.com/lit/an/slaa450b/slaa450b.pdf). It has a description of the files, initialization sequence, etc.

Based on what you mention, you'll probably need to change:

- PI (Peripheral Interface): we have examples for UART, USB, I2C, but you basically change the PI in order to get and receive data from your communication interface

- BSL430_Low_Level_Init: This is an assembly file which contains the first function executed by MSP430 in order to decide if BSL should be executed or not. For UART BSL, there's an entry sequence using the RST+TEST lines, but the USB BSL uses the PUR line or a blank reset vector. If you don't have any way to force such condition by the remote host, then you probably need to change this file based on your requirements.

The CI (Communication Interface) will probably be the same if you want to use the same commands (i.e, the BSL command will be the payload of your WiFi packets) but you can customize it according to your needs; and the BSL API will probably be the same since you are writing to flash in the same way.

One important consideration is that the BSL area is only 2KB, so you can't go crazy with the implementation. The USB BSL for example, has a smaller version of the BSL residing in this 2KB which doesn't support all commands, but it allows you to download the complete version of the BSL to RAM. Then the MSP430 jumps to RAM and executes the Full version of BSL.

The NFC BSL which communicates with the radio via SPI uses a similar approach: http://www.ti.com/lit/an/sloa160/sloa160.pdf

The benefit of BSL is that it resides in a reserved memory location and it's always accessible even after a mass erase, plus you have all the user flash for your application, including the interrupt vectors.

The other option, similar to the Flash Monitor from SLAA341 is to have the bootloader residing in "User" flash. In this case, you don't have the 2KB restriction, but the Flash is not protected from Mass Erase (you could still do segment erases) and you need to implement vector redirection.

The approach used by the AppNote is very compact and efficient but it's in assembly and it's not very modular. You would have to modify the implementation in order to use the USCI module (UART in F5xx), plus any additional steps required by your WiFi. 

The interrupt vector redirection from SLAA341 is also valid but the F5xx has Hardware vector redirection which could be more effective.

Regards,

Luis R