• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 1155 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430F6733: challenging The MSPBoot application report (slaa600a)

FrankEy
Prodigy 40 points

Part Number: MSP430F6733

Hello

We consider a bootloader implementation based on the MSPBoot slaa600a application report, in one of our MSP430F6733 based products.

One of our senior engineers was challenging the boot force mechanism (option 2)

It says in the report:

“

2.2.1.1 Force Bootloader Mode

Even with a valid application, bootloader mode can be forced by these options:

• Option 1: " .....  "

• Option 2: An application calls execution of bootloader mode. The variables StatCtrl and PassWd are reserved and shared between application and bootloader. To force bootloader mode, the application sets these variables to:

PassWd = 0xC0DE

StatCtrl.BIT0 = 1

“

But the shared variables (PassWd and StatCtrl) are written to RAM have a random value after reset, so:

1. Does those words retain their values after reset (how a ram retain its value after reset)?

2. When powering the device the shared variables  have a random value, so it is possible that

PassWd = 0xC0DE

StatCtrl.BIT0 = 1

And than we have an unexpected bootloader behavior.

How it is prevented?

 

Does anyone has experienced such problems?

Thanks

  • 0
    TI__Guru**** 223157 points
    Hello FrankEy,

    Option 2 assumes that there is valid application and bootloader code stored on the MSP430 device, which both share an agreed RAM space for the PassWd and StatCtrl. While running the application a command occurs that triggers the TI_MSPBoot_JumpToBoot function like seen in TI_MSPBoot_Mgr_Vectors_[xxxxx].c file of the App2_MSPBoot project. The PassWd and StatCtrl are updated in RAM and then an expired watchdog timer forces a PUC, a reset which does not erase the RAM contents. The bootloader (MSPBoot project) begins and checks if the boot mode has been forced by the application (TI_MSPBoot_AppMgr_BootisForced function from TI_MSPBoot_AppMgr.c), and the stored values of PassWd and StatCtrl from RAM will confirm that this is the case. This situation is different from a BOR or POR, which will erase the RAM contents and require an external event (Option 1) in order to force bootloader mode when a valid application is stored on the MCU.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Prodigy 40 points

    Hi Ryan

    Thanks for fast response. We were actually forced to boot by reseting using BOR and experienced no problems, so far… just wondered how come it works.

    Do you happen to have an answer for question 2?

    2. When powering the device the shared variables  have a random value, so it is possible that: PassWd = 0xC0DE and StatCtrl.BIT0 = 1, And than we have an unexpected bootloader behavior.

    How it is prevented?

    Many thanks

  • 0 in reply to FrankEy
    TI__Guru**** 223157 points
    Hi FrankEy,

    RAM is almost never truly random on power-up, it is typically either 0x00 or 0xFF. And the possibility of these 3 bytes randomly restarting at these exact values is 1 in 16.8 million.

    Regards,
    Ryan

**Attention** This is a public forum