MSPM0G1507: MSPM0G1507

Hi Dudley,

Dudley Hiller said:

I want to find out if I am in SWD Security level 1 or level 2. If only level 1, I need to know if there is a well-documented procedure that that will mass-erase or factory-reset the part?

SWD security will not make the influence on the factory-reset. So, I think factory reset could reset the device to inital stage. The factory reset has its own security level.

Dudley Hiller said:

If I hold the NRST pin low,

At this moment, the boot code is stuck with the NRST low, so the mcu will not run with normal stage. and it failed in the boot stage.

Maybe the slides in below thread could give you some guidance:

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1383220/mspm0l1306-mspm0-low-power-handling-with-pwr-ap/5291037#5291037 

B.R.

Sal

Sal,

I am starting to think that my problem has nothing to do with the SWD security. I suspect that this has to do with bad firmware loaded, effectively the reset vector providing a bridge to nowhere. The firmware that caused this problem was a .bin file that was incomplete size (not the expected 131072 bytes)

Do you think this is possible?

But I still wonder if there is any way to recover an ill-programmed part if the SWD cannot access the core address space.

Hi Dudley,

Actually, I think it possible, an incomplete firmware will cuase MCU run end in abnormal state, which might cause the MCU un-response. So the SWD connection or command is missed.

Most often, to execute a factory reset will sovle the problem. It will erase all tha MAIN flash firmware, and re-store the default NONMAIN firmware to the device, and then the device could be accessible.

B.R.

Sal

Sal,

It's a catch 22

From the slau846 Manual:

The configuration data in the NONMAIN flash region is not affected by a mass erase command, but it is erased and re-programmed to factory defaults by a factory reset command sent to the BCR via the debug sub system mailbox (DSSM) over SWD.

How do I do this if my SWD is not working??

Hi Dudley,

To achieve a factory reset by DSSM, in CCS with XDS110 (debugger of TI), will automatically reset the device and then send some command to let the device hold with SWD control.

As you know, there always need time to let the device run the boot code and then enter application code. So it remains time for debugger to control the device with some command.

I am not sure if you could successfully implement the DSSM over SWD? It is unrelated to SWD Security level. Do you ask for the guidance for how to implement them?

B.R.

Sal

Sal,

Does the XDS110 (debugger of TI) do the factory reset while holding NRST low?

When I hold NRST low the SWD gives me all of the correct ACK patterns. It just zeros out every address that I attempt to read.

Sal,

Never mind my last question.

Monday, I am going to attempt to recover my corrupted parts using the UART Bootloader described in slau887.

I have a question about the CMD Unlock Bootloader. Is the 32-byte password for this command stored in the NONMAIN memory? If so, where? I can't find this documented in the NONMAIN memory map in the reference manual. I assume that the factory default is all FFs Correct?

Hi Dudley,

Yes, the deafult is all 0xFF. You can find the description here:

B.R.

Sal

I am pleased to say that doing a Mass Erase with the UART Bootloader has restored the functionality of the SWD. So that reinforces my theory that dis-functional SWD was cause by the main flash programmed with an ambiguous reset vector.

Now I want to do a Factory Reset with the SWD. But I can't seem to connect the dots in the Reference Manual. The manual tells me how its disabled or password protected in the NONMAIN registers. But the manual leaves too much to the imagination about how to actually do it. My understanding is that the SWD Factory Reset will erase the NONMAIN and automatically reprogram it to factory defaults, is that correct? Do I simply load a factory reset command into the DEBUGSS.TXD register? Is there a written procedure for this.

Hi DUdley,

Dudley Hiller said:

I am pleased to say that doing a Mass Erase with the UART Bootloader has restored the functionality of the SWD. So that reinforces my theory that dis-functional SWD was cause by the main flash programmed with an ambiguous reset vector.

Mass erase is not expected to restore the SWD functionality. You can read the firmware in NONMAIN and check whether it change the NONMAIN. Something else should occurs. Maybe you don not successfully modify NONMAIN, something else prevent you connect SWD, for eample, a broken image to device might make the CPU run out of control, then you could not connect the SWD when the CPU is run away.

Dudley Hiller said:

My understanding is that the SWD Factory Reset will erase the NONMAIN and automatically reprogram it to factory defaults, is that correct? Do I simply load a factory reset command into the DEBUGSS.TXD register? Is there a written procedure for this.

Yes, factory reset via SWD will automatically restore the deafult NONMAIN data.

But I do not know the detail steps for how to implement the DSSM command with factory reset.

Actually, we gives a script in CCS to help customer use SWD factory reset. You can find it below, maybe it could help you:

GEL_DAPInit_remoteFactoryReset

Please let me aware if you need addtional instructions. I could forward to debugger expert and whether there is other documents you could refer.

B.R.

Sal