MSPM0G1507: Cannot automatically launch the program after flashing

Hi Tiger,

What program are you using to flash the device?

Regards,
Luke

Uniflash, web version.

The error applies to mac and linux, and no matter what form of xds110 we are using (M0L1306, M0G3507, or CC3220 launchpads)

But MSPM0L1306 target IC doesn't have the same issue.

Update:

On MacOS, if I am using native DSLite from following path:

/Applications/ti/uniflash/deskdb/content/TICloudAgent/osx/ccs_base/DebugServer/bin/DSLite help 
DSLite version 12.3.0.3041
DSLite [operation] [Args...]

...

It doesn't need reset!

I am not sure whether this links to certain program.

Hi Tiger,

Do you have the same settings between your MSPM0G and MSPM0L uniflash sessions? Specifically in regards to Reset Configuration.

Currently when the hard reset option is selected the code will auto run, you do not need to have the NRST pin connected because it is invoked via the SWDIO connection. I'm going to look into why the hard reset option is required.

Regards,
Luke

I have exactly same setting as your screenshot.

Hi Tiger,

I'm going to address what we talked about on the call.

The soft reset and hard reset are both done purely through software, where the soft resets intention is a CPU reset and the hard reset is a system reset. With a blank device or with BSL invoked the soft reset is not bringing the device to main, but a hard reset will due to the internals of the device. When a user uses a secondary BSL they will not run into this.

Regards,
Luke

After further investigate the issue. I added following codes:

void NMI_Handler(void) {
    DL_GPIO_setPins(GPIOA, DL_GPIO_PIN_24);
    while(1);
}

Then use CCS to attach debugger immediately after flashing the device (seeing non responding, no GPIO toggle). The PC indicate the code run to here. But GPIO doesn't seem to set.

Attached is my modified file. I just copy your examples from SDK (MSPM0G3507 example, convert to my target 1507)

/cfs-file/__key/communityserver-discussions-components-files/908/boot_5F00_application_5F00_mod.c

Another weird thing is that if I put a blocking shortcut while(1); to anywhere of the code, I can see PA24 being set. Otherwise, PA24 NEVER get set.

Note: MCUBOOT_LOG was disabled. optimization flag: -Os stack/heap 1024.

Further investigation:

When stopping, the SYSCTL->SOCLOCK.NMIIIDX indicating SRAM double error detect.

Can you please investigate it further?

Follow-ups:

Following codes can be workaround for me, but the reason of SRAMDED still unclear.

BTW, I tried SYSCTL_RESETLEVEL_LEVEL_CPU, doesn't work. POR/BOOTRST work.

void NMI_Handler(void) {
    if (SYSCTL_NMIIIDX_STAT_SRAMDED == DL_SYSCTL_getPendingNonMaskableInterrupt()) {
        DL_SYSCTL_resetDevice(SYSCTL_RESETLEVEL_LEVEL_BOOTLOADEREXIT);
    }
    while (1);
}

Hi Tiger,

Are you using a custom boot code or the boot code in the ROM?

Is the reset allowing your code to return to main?

I believe the GPIO not going high was a symptom of the SRAM DED error appearing before you initialized the GPIO.

Regards,
Luke

What do you mean "custom boot code"? I just follow example of bootmanger (mcuboot).

Weird thing is, if I remove mcuboot function calls and just have GPIO toggle, issue disappear.