Hello,
I am developing on the MSPM0L1306 Launchpad board.
After several erase/write cycles using the J-Link and debugging with the RTT, the MSP0l1306 locked up and will not reflash. I looked through the TI forums and it seems like this can be an issue if the NONMAIN flash section is flashed. I am not touching this section in my code.
I have had two separate boards lock-up when using a J-link only.
On my third board, I have only used the TI debugger and it has not locked up. I am concerned there is something wrong with the JLINK reflash algorithm that is causing this lockout.
Question: Is there some sort of recovery method for this chip that I can use with the JLINK? If I could write a script to do a mass erase or some sort of security reset that would be great if I could gain SWD reflash access again.
Toolchain: arm-none-eabi-gcc/arm-none-eabi-gdb 12.3 with JLink_V792h/JLinkGDBServerCLExe
Question: In the changelog, I see an update for the MSPM0 line in version 788, but I am using a higher version so I should be good there right?
Use case: I would like to debug with a J-Link as I would like to use the RTT protocol for logging.
Connection attempt output on locked device. VDD is good, and it looks like it finds devices on the SWD lines, but cannot connect. (See picture attached)
Hardware Connection: I have tested this adapter board and ribbon with some other hardware (Nordic Boards) and they are working via SWD on those boards. I have tried multiple different J-Links as well.
Jumpers: I have only the GND and 3.3V jumpers connected. All other jumpers are removed to isolate the onboard debugger from the JLINK. (See picture attached)
Corrective actions:
1. I have tried switching back to the onboard TI XDS110 debugger and issued a MASS ERASE, but this fails now that the chip is locked.
I am developing on the MSPM0L1306 Launchpad board.
After several erase/write cycles using the J-Link and debugging with the RTT, the MSP0l1306 locked up and will not reflash. I looked through the TI forums and it seems like this can be an issue if the NONMAIN flash section is flashed. I am not touching this section in my code.
I have had two separate boards lock-up when using a J-link only.
On my third board, I have only used the TI debugger and it has not locked up. I am concerned there is something wrong with the JLINK reflash algorithm that is causing this lockout.
Question: Is there some sort of recovery method for this chip that I can use with the JLINK? If I could write a script to do a mass erase or some sort of security reset that would be great if I could gain SWD reflash access again.
Toolchain: arm-none-eabi-gcc/arm-none-eabi-gdb 12.3 with JLink_V792h/JLinkGDBServerCLExe
Question: In the changelog, I see an update for the MSPM0 line in version 788, but I am using a higher version so I should be good there right?
Use case: I would like to debug with a J-Link as I would like to use the RTT protocol for logging.
Connection attempt output on locked device. VDD is good, and it looks like it finds devices on the SWD lines, but cannot connect. (See picture attached)
Hardware Connection: I have tested this adapter board and ribbon with some other hardware (Nordic Boards) and they are working via SWD on those boards. I have tried multiple different J-Links as well.
Jumpers: I have only the GND and 3.3V jumpers connected. All other jumpers are removed to isolate the onboard debugger from the JLINK. (See picture attached)
Corrective actions:
1. I have tried switching back to the onboard TI XDS110 debugger and issued a MASS ERASE, but this fails now that the chip is locked.