MSPM0G3507: BIM together with secondary BSL

Hi Zq,

When invoking the secondary bootloader from your application, are you accounting for BSL_ERR_01 from the MSPM0G3507 Errata?

Best Regards,
Brian

Hi Brian,

I checked BSL_ERR_01, and it doesn't seem to match my case. In that scenario, the BSL invocation fails because the SRAM is not completely cleared by the assembly code.

I have already added the SRAM clearing routine based on MSPM0 SDK 2.10.00.04.

Here is my software invocation code:

#ifndef BSL_INVOKE_H
#define BSL_INVOKE_H

#include "ti_msp_dl_config.h"

/**
 * @brief Invoke BSL (Bootstrap Loader).
 * @note This function erases SRAM and triggers a system reset to enter BSL mode.
 * @warning This function does not return; the system will reset.
 */
static inline void invokeBSLAsm(void)
{
    /* Erase SRAM completely before jumping to BSL */
    __asm volatile(
#if defined(__GNUC__)
        ".syntax unified\n" /* Load SRAMFLASH register*/
#endif
        "ldr     r4, = 0x41C40018\n" /* Load SRAMFLASH register*/
        "ldr     r4, [r4]\n"
        "ldr     r1, = 0x03FF0000\n" /* SRAMFLASH.SRAM_SZ mask */
        "ands    r4, r1\n"           /* Get SRAMFLASH.SRAM_SZ */
        "lsrs    r4, r4, #6\n"       /* SRAMFLASH.SRAM_SZ to kB */
        "ldr     r1, = 0x20300000\n" /* Start of ECC-code */
        "adds    r2, r4, r1\n"       /* End of ECC-code */
        "movs    r3, #0\n"
        "init_ecc_loop: \n" /* Loop to clear ECC-code */
        "str     r3, [r1]\n"
        "adds    r1, r1, #4\n"
        "cmp     r1, r2\n"
        "blo     init_ecc_loop\n"
        "ldr     r1, = 0x20200000\n" /* Start of NON-ECC-data */
        "adds    r2, r4, r1\n"       /* End of NON-ECC-data */
        "movs    r3, #0\n"
        "init_data_loop:\n" /* Loop to clear ECC-data */
        "str     r3, [r1]\n"
        "adds    r1, r1, #4\n"
        "cmp     r1, r2\n"
        "blo     init_data_loop\n"
        /* Force a reset calling BSL after clearing SRAM */
        "str     %[resetLvlVal], [%[resetLvlAddr], #0x00]\n"
        "str     %[resetCmdVal], [%[resetCmdAddr], #0x00]"
        : /* No outputs */
        : [ resetLvlAddr ] "r"(&SYSCTL->SOCLOCK.RESETLEVEL),
          [ resetLvlVal ] "r"(DL_SYSCTL_RESET_BOOTLOADER_ENTRY),
          [ resetCmdAddr ] "r"(&SYSCTL->SOCLOCK.RESETCMD),
          [ resetCmdVal ] "r"(SYSCTL_RESETCMD_KEY_VALUE | SYSCTL_RESETCMD_GO_TRUE)
        : "r1", "r2", "r3", "r4");
}

#endif /* BSL_INVOKE_H */

Hi Zq,

Since the debugger is stopping in both Default_Handler and NMI_Handler, it would help to know which one is
actually, being caught - they point to different root causes.

For NMI_Handler: the SYSCTL IIDX register will tell you which NMI source fired. The two maps below show the
possible sources - check SYSCTL IIDX against these to identify which event triggered it.

For Default_Handler: what peripherals do you have enabled in your secondary BSL, and do you have handlers for
each of them? If the application left any peripherals with pending interrupts before jumping to the BSL and the
BSL's vector table doesn't cover those, execution will land in Default_Handler. Walk through each peripheral's
IIDX register to find the unserviced interrupt.

Best Regards,
Brian

Hi Brian,

Thanks for your useful tips.
The issue is an NMI SRAM ECC error; I’ve attached a screenshot below.

However, I already clear SRAM before entering BSL. During debugging, I checked 0x20200000 and 20300000 ist cleared. Here is my BSL invoke code

#ifndef BSL_INVOKE_H
#define BSL_INVOKE_H

#include "ti_msp_dl_config.h"

/**
 * @brief Invoke BSL (Bootstrap Loader).
 * @note This function erases SRAM and triggers a system reset to enter BSL mode.
 * @warning This function does not return; the system will reset.
 */
__attribute__((optnone, noinline))
static void invokeBSLAsm(void)
{
    /* Erase SRAM completely before jumping to BSL */
    __asm(
#if defined(__GNUC__)
        ".syntax unified\n" /* Load SRAMFLASH register*/
#endif
        "ldr     r4, = 0x41C40018\n" /* Load SRAMFLASH register*/
        "ldr     r4, [r4]\n"
        "ldr     r1, = 0x03FF0000\n" /* SRAMFLASH.SRAM_SZ mask */
        "ands    r4, r1\n"           /* Get SRAMFLASH.SRAM_SZ */
        "lsrs    r4, r4, #6\n"       /* SRAMFLASH.SRAM_SZ to kB */
        "ldr     r1, = 0x20300000\n" /* Start of ECC-code */
        "adds    r2, r4, r1\n"       /* End of ECC-code */
        "movs    r3, #0\n"
        "init_ecc_loop: \n" /* Loop to clear ECC-code */
        "str     r3, [r1]\n"
        "adds    r1, r1, #4\n"
        "cmp     r1, r2\n"
        "blo     init_ecc_loop\n"
        "ldr     r1, = 0x20200000\n" /* Start of NON-ECC-data */
        "adds    r2, r4, r1\n"       /* End of NON-ECC-data */
        "movs    r3, #0\n"
        "init_data_loop:\n" /* Loop to clear ECC-data */
        "str     r3, [r1]\n"
        "adds    r1, r1, #4\n"
        "cmp     r1, r2\n"
        "blo     init_data_loop\n"
        /* Force a reset calling BSL after clearing SRAM */
        "str     %[resetLvlVal], [%[resetLvlAddr], #0x00]\n"
        "str     %[resetCmdVal], [%[resetCmdAddr], #0x00]"
        : /* No outputs */
        : [ resetLvlAddr ] "r"(&SYSCTL->SOCLOCK.RESETLEVEL),
        [ resetLvlVal ] "r"(DL_SYSCTL_RESET_BOOTLOADER_ENTRY),
        [ resetCmdAddr ] "r"(&SYSCTL->SOCLOCK.RESETCMD),
        [ resetCmdVal ] "r"(
            SYSCTL_RESETCMD_KEY_VALUE | SYSCTL_RESETCMD_GO_TRUE)
        : "r1", "r2", "r3", "r4");
}

#endif /* BSL_INVOKE_H */

I suspect it might be related to compiler optimization (e.g., -Oz), so I added some changes to prevent the compiler from optimizing the SRAM clear routine out. Unfortunately, the issue is still present. 

Are there any other possible reasons I might be overlooking that could cause this issue?

Best regards,
Zq