Best practices to guarantee SWD debugger access?

[scottm]

I seem to have a knack for getting devices into a state where I can't access them with a debug interface. Usually I'm able to do a mass erase with a P&E Cyclone, but today I've bricked two MK02FN64s to the point that I had to just replace them.

Whenever I've brought this up, support has told me that it must be because I'm changing pin or clock configurations too fast. The boards I'm having trouble with don't reuse any SWD pins so that leaves only the clock. On this particular board it switches at startup from the FRO to the PLL at 60 MHz.

To give the debugger time to connect, I added a simple loop before the clock and pin init functions. That made things worse; I think it must have gone into a watchdog reset loop, because that's when I bricked the second MCU.

What's the recommended way to guarantee that the SWD debugger is always able to connect on startup? The watchdog on this thing is set pretty slow, like maybe half a second, so I'm surprised that it takes the debugger longer than that.

I really miss the old, simple BDM debuggers where the debugger had control from the first clock cycle and it could always recover a chip.

Thanks,

Scott

[ErichStyger]

Hi @scottm ,

P&E has a utility which helped me in many cases: https://mcuoneclipse.com/2021/05/20/recovering-cortex-m-microcontroller-with-a-power-glitch/

The other thing I recommend is to have the reset pin available on the debug header, and not muxing that pin for something else: that way the debug probe can perform a pin reset and can try to catch the device while it is starting.

The other recommendation I have: keep the debug traces/cables short. 

Plus: have other debug probes available. I always have a J-Link, a PEMICRO and MCU-LInk at hand. I had many cases where two of them failed to catch a device, but one of the three was able to recover it. The reason is that they all have different capabilities and different timing or speed, making a difference.

I hope this helps,

Erich

[scottm]

Thanks, when I have time I'll put one of the bricked MCUs back on and see if that does it.

Looking at my logs from yesterday again, on the first attempt it's saying the reset pin state is 1 like it's got a bad connection or something. Not sure why that would be. I've tried multiple cables and verified continuity for NRESET. On the second attempt (and this is what I kept getting) it was giving me a flash driver startup failure:

Executing flash operation 'Erase' (Erase flash) - Tue Mar 03 16:28:00 PST 2026
Checking MCU info...
Scanning for targets...
Executing flash action...
LinkServer RedlinkMulti Driver v25.12 (Dec 8 2025 18:34:00 - crt_emu_cm_redlink.exe build 1160)
( 0) Reading remote configuration
Wc(03). No cache support.
Found chip XML file in B:/home/ads-ws1/Debug\MK02FN64xxx10.xml
( 5) Remote configuration complete
Reconnected to existing LinkServer process.
Connecting to probe 1 core 0 (using server started externally) reports:
'Ee(42). Could not connect to core.'
Retrying...
Reconnected to existing LinkServer process.
Server OK but no connection to probe 1 core 0 (after 3 attempts) - Ee(42). Could not connect to core.
============= SCRIPT: kinetisconnect.scp =============
Kinetis Connect Script
Connecting to Probe Index = 1
Error: Probe not connected
Error: Wire Ack Fault - target connected?
Assert NRESET
Reset pin state: 01
Error: Wire not connected
Power up Debug
Error: Wire not connected
Error: Wire not connected
No Debug Power
============= END SCRIPT =============================
Failed on connect: Ee(42). Could not connect to core.
No connection to chip's debug port
(100) Target Operation Failed
Unable to perform operation!
Command failed with exit code 1

Executing flash operation 'Erase' (Erase flash) - Tue Mar 03 18:08:14 PST 2026
Checking MCU info...
Scanning for targets...
Executing flash action...
LinkServer RedlinkMulti Driver v25.12 (Dec 8 2025 18:34:00 - crt_emu_cm_redlink.exe build 1160)
( 0) Reading remote configuration
Wc(03). No cache support.
Found chip XML file in B:/home/ads-ws1/Debug\MK02FN64xxx10.xml
( 5) Remote configuration complete
Reconnected to existing LinkServer process.
============= SCRIPT: kinetisconnect.scp =============
Kinetis Connect Script
Connecting to Probe Index = 1
This probe = 1
This TAP = 0
This core = 0
DpID = 2BA01477
Assert NRESET
Reset pin state: 00
Power up Debug
MDM-AP APID: 0x001C0000
MDM-AP System Reset/Hold Reset/Debug Request
MDM-AP Control: 0x0000001C
MDM-AP Status (Flash Ready) : 0x00000032
Part is not secured
MDM-AP Control: 0x00000014
Release NRESET
Reset pin state: 01
MDM-AP Control (Debug Request): 0x00000004
MDM-AP Status: 0x0001003A
MDM-AP Core Halted
============= END SCRIPT =============================
Probe Firmware: MCU-LINK (r0FB) CMSIS-DAP V3.167 (NXP Semiconductors)
Serial Number: IWUNAMQCTNCGT
VID:PID: 1FC9:0143
USB Path: 0002:002f:00
Using memory from core 0 after searching for a good core
( 30) Emulator Connected
( 40) Debug Halt
( 50) CPU ID
debug interface type = CoreSight DP (DAP DP ID 2BA01477) over SWD TAP 0
processor type = Cortex-M4 (CPU ID 00000C24) on DAP AP 0
number of h/w breakpoints = 6
number of flash patches = 2
number of h/w watchpoints = 4
Probe(0): Connected&Reset. DpID: 2BA01477. CpuID: 00000C24. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Content of CoreSight Debug ROM(s):
RBASE E00FF000: CID B105100D PID 04000BB4C4 ROM (type 0x1)
ROM 1 E000E000: CID B105E00D PID 04000BB00C Gen SCS (type 0x0)
ROM 1 E0001000: CID B105E00D PID 04003BB002 Gen DWT (type 0x0)
ROM 1 E0002000: CID B105E00D PID 04002BB003 Gen FPB (type 0x0)
ROM 1 E0000000: CID B105E00D PID 04003BB001 Gen ITM (type 0x0)
ROM 1 E0040000: CID B105900D PID 04000BB9A1 CSt TPIU type 0x11 Trace Sink - TPIU
NXP: MK02FN64xxx10
DAP stride is 4096 bytes (1024 words)
Inspected v.2 On chip Flash memory module FTFA_2K.cfx
Image 'SemiGeneric Dec 8 2025 17:18:55'
Opening flash driver FTFA_2K.cfx
Sending VECTRESET to run flash driver
AFTER driver startup timeout (302 5ms retries)
Driver Addresses
Start: 20000000
Entry: 2000009D
End: 200006D8
Stack: 200007D8
Mailbox:200017D8
Driver Register State
R0: 00000000
R1: 00000000
R2: 1FFFFA1F
R3: 00000001
R4: 00000000
R5: 00000100
R6: 00001343
R7: 0008FB3B
R8: 00000000
R9: 00000000
R10: 00000000
R11: 00000000
R12: 0000000A
SP: 20001F98
LR: 0000464F
PC: 0000464E
xPSR: 01000000
MSP: 20001F98
PSP: 00000000
CFBP: 04000001 (CONTROL=0x4, FAULTMASK=0x0, BASEPRI=0x0, PRIMASK=0x1)
Flash Driver V.2 startup failed - rc Ef(34): Timed-out initializing flash.
chip initialization failed - Ef(34): Timed-out initializing flash.
failed to initialize flash driver FTFA_2K.cfx
( 65) Chip Setup Complete
(100) Target Operation Failed
Unable to perform operation!
Command failed with exit code 1

[Celeste_Liu]

Hello @scottm ,

Thanks for sharing the detailed logs.

From the first attempt, it looks like the RESET and SWD signals are not stable. It may be worth checking the SWD cable length, grounding quality, and whether there are strong pull‑ups or large RC components on the RESET line.

In the second attempt, the timeout during flash driver startup usually indicates that the MCU is stuck in an invalid clock configuration, or that a reset occurred in the middle of a flash operation.

Common causes are:

The PLL failing to lock or using an invalid clock source

The clock running out of spec, causing the flash driver (executing from RAM) to fail

A previous watchdog reset during flash programming

Please try connect under reset, timed reset, or power‑glitch recovery as Erich suggested.

Have a nice day!

BR

Celeste

[scottm]

Hi Celeste,

After some more investigation, it looks like the two MCUs that I couldn't recover at all may have been victims of a bootloader bug that improperly decrypted a new firmware image, so it's possible the flash security bits got scrambled in this case. RESET stability shouldn't be an issue; it's a straight shot of a couple of centimeters from the MCU to the SWD header, and the ribbon cable is short.

I'm just getting started with my HIL lab rack and remote debugging setup but interestingly so far it seems like things have been more stable using a "GDB Hardware Debugging" debug configuration connecting to a Raspberry Pi running OpenOCD with an MCU-Link Pro than when I use LinkServer locally with the same hardware.

A lot of my debugger frustrations lately have traced their origin back to bad documentation for the LPC55S69. Both P&E and NXP got the flash memory layout wrong (it's wrong in some places in the reference manual) and both have fixed it, but MCUXpresso projects created before the fix still carry the incorrect memory configuration and have to be manually fixed. That's not the issue this time with the K02 but it's certainly been making it feel like the debuggers are unreliable.

Thanks for your response, and I'll keep a close eye on the MCU-Link behavior going forward to see if the problem comes back.

Scott