MSPM0L1303: best practice when using SWD pin as GPIO yet still keep the debug access.

xiao feng

Part Number: MSPM0L1303
Other Parts Discussed in Thread: SYSCONFIG, UNIFLASH

I did the same thing as this guy: disable the SWD pin, and lose programming access to the MCU

MSPM0L1304: re-gain debug access via NRST - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

So there is still no way to recover the MCU if I do not have bootloader and disable SWD access from the start?

As I have limited board to play with, I think Yuhao Zhao's number 2 solution sounds pretty great.(add a delay before disabling SWD access)

Could you please help me to check that this is the correct thing to do, or is there anything i missed?:

1. in sysconfig, leave the "Debug Enable On SWD Pins" ticked. do not initialize the intended gpio pin

2. in main, use delay_cycles(??) to delay for a few second

3. use code below to disable debug

SYSCTL->SOCLOCK.SWDCFG = (SYSCTL_SWDCFG_KEY_VALUE | SYSCTL_SWDCFG_DISABLE_TRUE);

4. initialize the intended gpio pin

Thank you very much

over 2 years ago

0 Dennis Lehman over 2 years ago

TI__Guru 71216 points

Hello Xiao,

I agree, #2 should do the trick. Do you still have control of the NRST pin? Have you tried his other suggestion to hold the NRST low for a longer period of time while the debugger attempts to connect?

0 xiao feng over 2 years ago in reply to Dennis Lehman

Prodigy 130 points

Yes I still have control of NRST pin.
that sounds like great news. I will try it out. Thank you

0 xiao feng over 2 years ago in reply to Dennis Lehman

Prodigy 130 points

neither uniflash nor debugging using CCS works, when SWD is disabled in code + hold NRST low
but if I hold nrst low, connect to CS_DAP_0 core, and use FactoryReset_Manual DAP script, it will allow me to program the next time i try. i wander if there is a way to do this with uniflash only. i will ask this in a separate thread.