MSP430FR5994: WDT reset failes with custom bootloader.

Antonio Alborini

Part Number: MSP430FR5994

Hi everyones,

I've developed an application for my MSP430FR microcontroller based on a custom bootloader and main application. At power-up the the bootloader verifies if there is a fw upgrade request and, if not, the main application is started. In case the user wants to upgrade the firmware (while the main application is running), the application resets itself and the bootloader is started.

If the reset is done by a software BOR, everything works fine. On the other hand, if the reset is done by using the WDT reset, the application breaks in some unknown state/address. Of course i need to use the WDT functionalities in my application not only for the fw upgrade.

I've already verified the reset vector (0xFFFE) content before triggering the WDT reset, and it is extactly the bootloader entry point.

If I fully remove the bootloader from the project running only the main application, WTD resets work as expected resetting always to the main application entry point.

Do you have some idea/suggestions about where the problem could be?

Thanks in advance for your help.

over 4 years ago

0 James Evans over 4 years ago

TI__Mastermind 49692 points

Hello,

Are you using the MSP430FRBOOT for your custom bootloader? Looking at the App1_MSPBoot_FR5994_UART project, the TI_MSPBoot_JumpToBoot() function is called in the Port 5 ISR in 'main1.c'. That function is defined in 'TI_MSPBoot_Mgr_Vectors_FR59xx.c' and performs a software BOR to switch from application mode to boot mode.

void TI_MSPBoot_JumpToBoot( void )
{
    PassWd = BSL_PASSWORD;      // Send password
    StatCtrl |= BOOT_APP_REQ;   // Set flag to request boot mode
    __disable_interrupt();      // Disable all interrupts
    // Force a Software BOR
    PMMCTL0 = PMMPW | PMMSWBOR;
    while (1)
        ;

}

In the MSPBoot_FR5994_UART project, 'boot.c' initializes the stack and calls the main_boot() function to start the bootloader. If you use a WDT reset, most likely the boot code is not executed which could be why you're seeing this issue.

Another idea would be to make sure your CCS project settings have disabled the Memory Protection Unit (MPU).

0 Antonio Alborini over 4 years ago in reply to James Evans

Prodigy 10 points

Hi James,

Thanks for your help. it was indeed an issue related to the MPU. Just a quick explanation that can be useful for future users facing the same issue.

The MPU of the MSP uc is able to protect some area of the FRAM preventing the execution of code. Assume the following situation:
- Both the main code and the bootloader have their own "start-address".
- Once the main code is executed, the MPU protects the memory addresses before the start-address of the main code.
- This means that no execution of code is allowed before the starting address of the main code.
- Be aware that this MPU configuration is done automatically by the compiler!

BOR ans WDT reset behave in a different way with respect to the MPU configuration:

-In case of BOR reset, all the MPU restrictions are temporary disabled which exaplains why everything was working fine and why the bootloader (even if has its own code before the main code starting address) was running correctly.
-In case of WDT reset, the MPU protections are still there and the bootloader remains frozen.

The solution here is to play with the MPU registers. The MPUSEGBx registers allow the user to define the areas of the memory where the MPU restrictions are valid. By setting these registers correctly no matter if BOR or WDT reset but the bootloader seems to work always fine.

Hope this can help.

0 James Evans over 4 years ago in reply to Antonio Alborini

TI__Mastermind 49692 points

Hi Antonio,

That's fantastic news. Thanks for letting me know and also for sharing such a detailed summary.

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430FR5994: WDT reset failes with custom bootloader.