MSPM0G3519: SWD access blocked after unexpected power loss during flashing

Hey Francois,

This is a unique scenario as the application was only partially programmed which means that behavior of the application execution is then unpredictable.

From your description it seems like the device had encountered a nested exception upon wake-up but was it really a POR that had occurred or was it a BOR?

However, the best explanation I could provide is that the partial code is leading to unpredictable behavior in the CPU leading to the nested exception causing CPU lock.

Thank you,

Henry Nguyen 

Hello Henry,

Thank you for having got back to me.

The MCU should have gone through a POR because the power supply was interrupted, meaning Vdd dropped below the POR- threshold described in datasheet section 7.6.1 Power Supply Ramp.

Are you saying that the SWD cannot take control of the M0+ core when it is locked somewhere, liked because of nested exceptions it cannot return from? Since the MCU went through POR that re-enables debug (if not disabled in NONMAIN), why would the SWD be unable to halt the M0+ core?

Best regards,
François.

Hello Henry,

Could you please come back to me asap?

Best regards,
François.

Hey Francois,

Sorry for the late reply.

If you have incomplete code within flash then the behavior becomes unpredictable.

Upon connection to the MCU while  the unknown application is running you run the chance of it working or not working depending on where it is in execution of the incomplete application which you run the chance of running into the nested exception again preventing connection.

Hi Henry,

Thank you, however that does not help enough. Could you please answer precisely my questions:

Are you saying that the SWD cannot take control of the M0+ core when it is locked somewhere, like because of nested exceptions it cannot return from? Since the MCU went through POR that re-enables debug (if not disabled in NONMAIN), why would the SWD be unable to halt the M0+ core?

Best regards,
François.

Hi Francois,

When you power on a device with firmware existing in MAIN flash, it will then execute the firmware. The MCU will execute what is present in the flash.

In your case, you are allowing the device to execute bad firmware, that will have unpredictable behavior. Execution of the application does not take several minutes, it will be instantaneous upon powering the device on.

This means the second you power it on you then you are allowing the device to just run into the scenario where it is most likely executing improper application code leading to the nested exception again preventing access at the time you are attempting access to the M0 core itself stopping you from halting the device.

To resolve this, mass erase or factory reset the device and then properly load in the application to see if you are able to connect.

Is this clear?

Thanks

Hi Henry,

Are you saying that if the Arm M0+ core executes some illegal instructions because the flash is improperly programmed, the SWD cannot take the hand on the core so to inspect registers, memory, etc.? That would be surprising? Which cases would you see that such access is impossible for the SWD?

Best regards,
François.

It just depends the severity of what is done at the end of the day.

For MSPM0 devices we offer the DSSM commands allowing you to regain access to the device in such scenarios.

Just general bad practices like de-referencing a null pointer at your SP. The list goes on, but you can get the general idea if the user were to do something that is obviously improper it leads to such scenario.

Hi Henry,

Thank you. Could you please list the relevant DSSM commands and how to execute them? Ideally, using IAR and J-Link, but CCS+XDS110 is acceptable as well since this would just be to recover bricked parts.

Best regards,
François.

Thank you, Henry.