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.

SLAA450 and SLAU319i, BSL

Using CCS v5.5, MSP4305418A.

Trying to implement a means to upgrade product firmware in the field via UART. I do not have easy hardware access to TCK and RST.

I have downloaded MSPBoot_1_01_00_00 main memory bootloader code, compiled and loaded it on a G2553 dev board. I have loaded a program via the UART, it works.

The problem:
The main memory bootloader code does not support addresses >64k (only two bytes in the message protocol).

I then downloaded SLAA450 and see that it supports 3 byte addresses and some other functions that the main memory bootloader does not.

The other problem:
The code from SLAA450 does not use a pseudo vector table and writes the reset vector. While I think I could download a program as it is, it would have to always have the reset vector pointed at the BSL. When the vector table is erased and re-written for each program that is loaded, there is a small window of time where power loss would brick the device as the reset vector would be erased.

My options as I see it:
Add vector redirection to SLAA450 and hard code protection for the vector space.

Change protocol in MSPBoot to support larger address space.

Will someone confirm? Am I missing anything?

  • Hi Shawn,

    For MSP430F5xx/6xx, I definetively recommend you to use BSL if you can, especially if you can make it fit in the 2KB area.

    Please note that SLAA450 talks about customizing the Flash BSL in F5xx/F6xx in the first section ("Flash BSL"), and it talks about a different bootloader for G2xx ("vBSL") in the second section.

    As mentioned in Section 2.2.1.3, vBSL has a potential vulnerability which can brick the MCU if power is lost after the reset vector is erased. But the Flash BSL doesn't have this problem.

    Section 1.2 explains the entry sequence to Flash BSL, and basically you won't brick the MCU even if you don't have a reset vector. A function known as "BSL Protect" is always executed after a BOR and you can use that function to decide if you want to stay in Bootloader mode, or jump to application. BSL also has the the advantage of using Hardware-protected memory, but its biggest disadvantage is that you only have 2KB of memory (unless you use info Memory or part of main memory).

    Finally, MSPBoot was created especially for customers who want to customize their bootloader but have devices with ROM BSL, and they need more functionality compared to vBSL. I have heard a couple of customers asking for MSPBoot for F5xx/F6xx, mostly because it allows them to use more memory, but there are no plans to add it in the near future.

    Here's a presentation talking about the different MSP430 bootloaders in case you are interested:

    2766.Comprehensive Guide to BSLs.pdf

    Regards,

    Luis R

  • So,

    Modify BSL_Protect to check for a hardware condition that signals to stay in the bootloader.

    As long as it fits in 2kB BSL space, I can modify BSL code to use the USCI instead of software UART (implemented with the timer and P1.1 and 1.2).

    -shawn

  • Correct.The default entry sequence for BSL_Protect checks SYSCTL.SYSBSLIND which gets set when it detects a pattern on RESET+TEST pins. 

    And you can modify the Peripheral Interface (PI) to use USCI-UART or other interfaces.

    Regards,

    Luis R

  • My assembly is a little (ahem) rusty, but I should be able to do this.

    This is great, thank you. 

    -shawn

**Attention** This is a public forum