MSPM0G3105: Error -6305 PRSC module failed to write to a router register (Emulation package 9.12.0.00150)

Hi Nicola,

What SDK version are you using? Are you using TIClang or GCC? 

There was an issue with the linker for GCC in older versions of the SDK that could occasionally cause flash corruption due to mishandling of the flash loader.

To recover the boards you are having issues with now, can you try our MSPM0 Factory reset tool? https://dev.ti.com/gallery/view/TIMSPGC/MSPM0_Factory_Reset_Tool/ver/0.0.3/

Some users have trouble installing the extensions required for that GUI, so if that doesn't work you can also try to do a factory reset via CCS as described here: https://dev.ti.com/tirex/content/mspm0_sdk_1_20_01_06/docs/english/tools/ccs_ide_guide/doc_guide/doc_guide-srcs/ccs_ide_guide.html#dssm-mass-erase-and-factory-reset

Best Regards,
Brandon Fisher

Hi Brandon,

I'm using SDK version 1.20.1.06 and GCC v. 9.2.1 (Linaro).

I've used the MSPM0 Factory Reset Tool but when I try to connect to my XDS110 debugger I get this error: "Failed to connect: there is no active configuration to connect with". I've installed latest TICloudAgent Bridge app but it doesn't change the result.

I've also tried to do a factory reset via CCS as described in the 3.5.1 DSSM Mass Erase and Factory Reset chapter you sent me the link. However, when I try to do that, I get in the console output:

CS_DAP_0: GEL Output: Initiating Device Mass Erase
CS_DAP_0: GEL Output: Attempting CS_DAP connection
CS_DAP_0: GEL Output: Attempting SEC_AP connection
CS_DAP_0: GEL Output: Command Sent
CS_DAP_0: GEL Output: Start hardware Reset using NRST
CS_DAP_0: GEL Output: Initiating BOOTRST Board Reset
CS_DAP_0: GEL Output: Reset line asserted
CS_DAP_0: GEL Output: Reset line de-asserted
CS_DAP_0: GEL Output: Board Reset Complete
CS_DAP_0: GEL Output: Reset done
CS_DAP_0: GEL Output: SEC_AP Disconnect
CS_DAP_0: GEL Output: SEC_AP Reconnect

And I get two windows showing "GEL Expression: GEL_DAPInit_SECAPCommand()" and "GEL Expression: MSPM0_MailboxMassErase_Auto()" processes running (the progress bar is continuously going on) but actually nothing is happening.

I've tried, as suggested in the 3.5.1 DSSM Mass Erase and Factory Reset chapter, to force RESET low and use the "manual" version of the command, but the result is the same with those two windows running but nothing really being done.

Do you have any other suggestion?

Thank you,

Nicola

Hi Nicola,

With CCS 12.4 and GCC you could still see the issue I described. I'd recommend upgrading to CCS 12.5 just to be cautious.

On the topic of attempting to recover the devices. It sounds like Mass Erase and Factory reset may be disabled. Were you intentionally modifying NONMAIN memory at all? If NONMAIN was left erased, then a device can be locked out completely with all methods of access disabled.

Another way you can attempt to access the device is to invoke BSL. Do you have access to the BSL invocation pin? It is PA18 by default. If this is the launchpad, you can hold down S1 and trigger a reset with the NRST pin, keep S1 held down until you release NRST and the device will boot into BSL mode. 

At that point, assuming BSL is still enabled, you should be able to program the device. 

Best Regards,
Brandon Fisher

Hi Brandon,

ok thank you. I'll use CCS12.5.

I've not erased the NONMAIN memory but maybe I happened to debug this MCU selecting a different one (i.e. MSPM0G3705). Could this have caused the locking of the MCU?

I'm not using the launchpad but my own board. However I'll try to use BSL for booting the device and reprogram it. And then I'll let you know.

Thanks,

Nicola

Understood Nicola,

Let me know the results of the BSL Test.

Programming this device for MSPM0G3507 accidentally should not erase nonmain your device. You may see an error message, but as long as you are not using the extra memory you shouldn't have any flashing issues like this afterwards. 

Best Regards,
Brandon Fisher

Hi Brandon,

I've tried to enter the MCU in BSL mode but it doesn't change. This is what I've done:

1- I've powered off the board

2- Connected BSL pin (PA18) and NRST pin to GND

3- Powered on the board

4- remove GND from NRST

5- Launched the MSPM0G3507.ccxml configuration

6- Launched the MSPM0_MailboxMasseraseAuto script

Doing so I get these messages in the console:

CS_DAP_0: GEL Output: Initiating Device Mass Erase
CS_DAP_0: GEL Output: Attempting CS_DAP connection
CS_DAP_0: GEL Output: Attempting SEC_AP connection
CS_DAP_0: GEL Output: Command Sent
CS_DAP_0: GEL Output: Start hardware Reset using NRST
CS_DAP_0: GEL Output: Initiating BOOTRST Board Reset
CS_DAP_0: GEL Output: Reset line asserted
CS_DAP_0: GEL Output: Reset line de-asserted
CS_DAP_0: GEL Output: Board Reset Complete
CS_DAP_0: GEL Output: Reset done
CS_DAP_0: GEL Output: SEC_AP Disconnect
CS_DAP_0: GEL Output: SEC_AP Reconnect

and then I still get the two windows showing "GEL Expression: GEL_DAPInit_SECAPCommand()" and "GEL Expression: MSPM0_MailboxMassErase_Auto()" running forever...

Do you have any other suggestion to unlock the MCU?

I have another question: can wrong changes in the clock settings (PLL or other) lead to this locking/error MCU condition?

Thank you,

Nicola

Hi Nicola,

Nicola Ciot said:

2- Connected BSL pin (PA18) and NRST pin to GND

I should have been more specific. The PA18 pin should be pulled high during reset (by default) to invoke BSL mode, not pulled low. Try again with that pin pulled high. 

If you cannot connect after invoking BSL mode, in combination with the the inability to factory reset, mass erase, or connect to the device normally, its likely the device's nonmain was erased and/or reprogrammed unintentionally. 

Nicola Ciot said:

I have another question: can wrong changes in the clock settings (PLL or other) lead to this locking/error MCU condition?

I wouldn't necessarily expect the clock settings to cause an issue that left the device unprogrammable. It may make it impossible to connect to the device after the clock is reconfigured in your application, but, if enabled, the invocation of BSL would prevent the application code from running, and therefore the device and clock would be in default settings. At that point you should be able to connect.

Best Regards,
Brandon Fisher