MSPM0G3507: Not able to program MSPM0G3507SRHBR

Hi AB,

How to power supply your hardware? via XDS110-ET or not?

And have you tried follow this guide to factory reset your device?

 MSPM0G3507: Resetting device to factory settings 

From hardware design side, Reset connect will prefer, but not mandatory.

Thanks!

Best Regards

Johnson

Hello, thanks for the reply. 

I don't supply it via XDS110, my hardware is powered separately. I have checked the power at Pin 4 it was as expected 3.3v.

I tried this MSPM0_Factory_Reset_Tool tool but it didn't recognise my device (doesnt attach).

I was able to do some work around and get a pullup at NRST now when I try to program it by manual probing my NRST every time I get one of the following:

Error connecting to the target: (Error -615 @ 0x0) The target failed to see a correctly formatted SWD header. The connection to the target may be unreliable. Try lowering the  TCLK setting before trying again. (Emulation package 20.1.0.3429) 

or,

Failed CPU Subsystem Reset: (Error -1001 @ 0x0) Requested operation is not supported on this device. (Emulation package 20.1.0.3429)
Error: Connection to MSPM0 core failed. Possible root causes: 1) Debug access within NONMAIN was disabled or enabled with password. 2) Peripheral mis-configuration (e.g improper watchdog or clock). To see a more detailed diagnostic of the issue, please press the 'Read boot diagnostic' button.

or, 

CS_DAP_0: Error connecting to the target: DAP Connection Error. This could be caused by the device having gone to low power mode. Try forcing an external reset.If the error persists, try forcing BSL, a Mass erase or a Factory Reset. Check device FAQs for more information.
Failed to retrieve the Wait in Reset Mode: (Error -6311) PRSC module failed to write to a register. (Emulation package 20.1.0.3429)
Error connecting to the target: (Error -6311) PRSC module failed to write to a register. (Emulation package 20.1.0.3429)

or 

Failed CPU Subsystem Reset: (Error -2063 @ 0x0) Unable to reset device. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.1.0.3429)
JTAG Communication Error: (Error -615 @ 0x0) The target failed to see a correctly formatted SWD header. The connection to the target may be unreliable. Try lowering the TCLK setting before trying again. (Emulation package 20.1.0.3429)                                                                                    CS_DAP_0: GEL: Error while executing PWRAP_DPREC0 = PWRAP_DPREC0 | 0x00020000: Could not read register PWRAP_DPREC0: target is not connected at (PWRAP_DPREC0|0x00020000)

Currently I have my TCLK configured at 100.0KHz from .ccxml.

Johnson He said:

From hardware design side, Reset connect will prefer, but not mandatory.

Yes, the datasheet mentions the same but, in my case the two-wire interface doesn't seem to work.

[edit: added latest error to the list of errors that I get.]

A B said:

I was able to do some work around and get a pullup at NRST now when I try to program it by manual probing my NRST every time I get one of the following:

Sorry about this vague information here. 

Initially I had my Pin 3 and Pin 4 shorted (NRST and VDD), now I have managed to cut the trace, add a pullup resistor to the NRST trace and whenever I need to program, I connect another wire from J102 Pin 10 (from the LaunchPad) and probe it to the resistor pad.

Hi, A B 

Check this first, do you use this tool to program?

https://www.ti.com/tool/LP-XDS110ET

If yes,

A B said:

Connected J102 SWDIO -> target SWDIO (PA20)
Connected J102 SWCLK -> target SWCLK (PA19)

There shouldn't be SWDIO and SWCLK on LP-XDS110-ET,

on its bottom layer,

TMS = SWDIO

TCK = SWCLK

3V3 = 3V3

GND = GND

it's better to connect

nRST = NRST

Hello Helic Chi ,

Helic Chi said:

Check this first, do you use this tool to program?

https://www.ti.com/tool/LP-XDS110ET

I'm not using a dedicated LP-XDS110ET rather, I'm using the on-board XDS110-ET available in the LP-MSPM0G3507.

Yes, the signals are not SWDIO and SWCLK, they are TMS_ SWDIO and TCK_SWDCLK.

Helic Chi said:

• Hardware check, check power supply(customer defined, 3.3V), check Vcore voltage(1.35V).
• Check XDS110 connection with PC, it’s in your PC’s device manager list.

My voltage at VDD is 3.29 ~ 3.3 but I just noticed that my V_CORE voltage is at 2.65V! I think this is what is causing my problem. 

I have confirmed there is no short between VDD and VCORE. Although I am using a 1uF capacitor at V_CORE instead of the recommended 0.47uF, I expect this would only affect startup time rather than causing such a significant voltage increase. 

Is there anything else I am missing which have caused the V_CORE to shoot up like this?

Thank you. 

A B said:

My voltage at VDD is 3.29 ~ 3.3 but I just noticed that my V_CORE voltage is at 2.65V! I think this is what is causing my problem. 

It's broken, maybe caused by high voltage from external.

A B said:

I expect this would only affect startup time rather than causing such a significant voltage increase. 

Yes, startup time, it's better to use a 0.47uF.

A B said:

Is there anything else I am missing which have caused the V_CORE to shoot up like this?

It's unclear, but typically, an increase in output voltage is caused by physical damage, such as a breakdown of the internal 1.35V LDO.

Helic Chi said:

It's unclear, but typically, an increase in output voltage is caused by physical damage, such as a breakdown of the internal 1.35V LDO.

So, if I'm not wrong replacing the MCU should solve the CS_DAP error. 

Helic Chi said:

Yes, you need to replace with a new M0.

Will do, Thanks. 

Are there any failsafe mechanisms, register level controls, or configuration safeguards to prevent damage to the internal LDO?

A B said:

Are there any failsafe mechanisms, register level controls, or configuration safeguards to prevent damage to the internal LDO?

This should be physical damage caused by external factors.

It's better to check your development condition, such as make sure all input voltage are within the datasheet spec.

And normally, it's not very common to see a Vcore damage.

Helic Chi said:

Yes, you need to replace with a new M0.

Replacing it did solve my issue - I'm able to program my device now. BUT the V_CORE is not at 1.35V! after I replaced it and powered it on, it started at 1.7V and after a few hours of use it increased to 2.04V. 

A B said:

started at 1.7V and after a few hours of use it increased to 2.04V. 

That's impossible!

Vcore should keep at 1.35V, +/-10% is OK, but it's better keep in +/- 5%.

Is this your customized PCB board or official EVM from TI LP-MSPM0G3507?

Is the Vcc normal? within spec 1.62 < VDD < 3.6V?

Helic Chi said:

That's impossible!

Vcore should keep at 1.35V, +/-10% is OK, but it's better keep in +/- 5%.

Helic Chi said:

Is this your customized PCB board or official EVM from TI LP-MSPM0G3507?

Customized PCB, Package is MSPM0G3507SRHBR (32-pin). 

Helic Chi said:

Is the Vcc normal? within spec 1.62 < VDD < 3.6V?

Yes, VDD is 3.3V.

Replacing the MCU did solve my original problem with not being able to flash the program, but it has introduced some new issues. The ADC no longer seems to work. I can measure voltages at the ADC pins (PA15, PA16), but when I run my previously tested code, I’m unable to read any voltage. I also tried changing the ADC reference from the internal VREF to VDDA, but it made no difference.

A B said:

The ADC no longer seems to work. I can measure voltages at the ADC pins (PA15, PA16), but when I run my previously tested code, I’m unable to read any voltage.

To verify the ADC, maybe need to test whether pin soldering is good and whether ADC core is good.

Try to use ADC to sample internal Vdd channel to verify ADC code first.

Also, you can try to measure pin voltage (measure directly from package's pin), this is not a easy to test method...

A B said:

BUT the V_CORE is not at 1.35V! after I replaced it and powered it on, it started at 1.7V and after a few hours of use it increased to 2.04V. 

If this phenomenon persists, please carefully check your hardware and compare it with the LP development board.

Also, if you are using sample units, please request a new batch for testing.

Helic Chi said:

To verify the ADC, maybe need to test whether pin soldering is good and whether ADC core is good.

Pin soldering is good, need to check the ADC core to sample internal VDD. 

Helic Chi said:

If this phenomenon persists, please carefully check your hardware and compare it with the LP development board.

New information regarding this, my device stopped flashing codes again. 

Now, 

Upon powering on, the V_Core is at 0.5V and when I connected my XDS110 (from LP), the voltage raises to 1.67 - 1.7.

previously upon powering my device alone gave me V_Core of ~1.7. 

Helic Chi said:

Vcore should keep at 1.35V, +/-10% is OK, but it's better keep in +/- 5%.

A B said:

Initially I had my Pin 3 and Pin 4 shorted (NRST and VDD), now I have managed to cut the trace, add a pullup resistor to the NRST trace and whenever I need to program, I connect another wire from J102 Pin 10 (from the LaunchPad) and probe it to the resistor pad.

Is it possible that the rework I’m doing is causing the issue with V_CORE? After I replaced the MCU, it worked for some time, but then it went into thermal runaway.

I did test another on my boards in which I don't have any above mentioned reworks done, in that the V_CORE voltage is at 1.35 but I still can't flash the board because the NRST is tied to VDD without pullup. (I get CS_DAP_0: error) 

A B said:

Is it possible that the rework I’m doing is causing the issue with V_CORE? After I replaced the MCU, it worked for some time, but then it went into thermal runaway.

There's a low probability of causing physical damage, but prolonged exposure to high temperatures during the soldering process could still damage the chip.

A B said:

I did test another on my boards in which I don't have any above mentioned reworks done, in that the V_CORE voltage is at 1.35 but I still can't flash the board because the NRST is tied to VDD without pullup. (I get CS_DAP_0: error) 

At least 1.35V Vcore shows that there is no physical damage here, but DAP connection error always cause by 1. SWD connection issue, 2. nonmain erase issue. For #1, please check hardware connection. For #2, need replace a new M0.

Solved the CS_DAP_Error now, 

JTAG Communication Error: (Error -1001 @ 0x0) Requested operation is not supported on this device. (Emulation package 20.1.0.3429) Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

My JTAG TCLK frequency set through .ccxml is 100KHz.

After this, I tried to reset the board using MSPM0 MCUs Development Guide (Rev. G) ( scrpits -> factory reset auto). I get the following:

CS_DAP_0: Trouble Reading Register SECAP_RCR: (Error -2131 @ 0x2020C) Unable to access device register. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.1.0.3429)
CS_DAP_0: GEL: Error while executing GEL_DAPInit_SECAPCommand(): Target failed to read register SECAP_RCR
at ('REG'::SECAP_RCR&0xFFFFU) [mspm0_cs_dap_init.gel:247]
at GEL_DAPInit_WaitForResponse() [mspm0_cs_dap_init.gel:426]
at GEL_DAPInit_SECAPCommand()

I have tried - power cycling the board, I have lowest possible TCLK setting, There is no mention of any register "SECAP_RCR" I was only able to find "SECAPEN" in 31.3.13

Two method: 

1. When available, CCS will tell you to read bootdiag, if available, send its value to me.

2. Enter BSL mode and try Factory reset manually, need manually push the reset button.

Here is the common step to recovery a MSPM0: