Inconsistent DM-AP attach behavior when attaching J-Link/Ozone to LPC55(S)28 in (Deep)Power Down

[PaulaVelasco]

Hi,

We're seeing inconsistent SWD attach behavior when connecting Ozone (J-Link) to an LPC5528 or LPC55S28 that's in Power Down or Deep Power Down mode, using Debug.SetConnectMode(CM_ATTACH_HALT). We've reproduced different outcomes across two 'identical' custom boards running LPC5528 and an NXP evaluation board running LPC55S28 - all revision 1B -, and would like clarification on the expected Debug Mailbox recovery flow.

Setup

MCU: LPC5528 and LPC55S28
Debug probe: J-Link
Tool: Ozone, Debug.SetConnectMode(CM_ATTACH_HALT)
Power modes tested: Power Down and Deep Power Down (entered via POWER_EnterPowerDown() / POWER_EnterDeepPowerDown())

Observation 1 — Board A, custom board, LPC5528, both Power Down and Deep Power Down

DM-AP IDCODE never resolves; attach fails outright after 4 retries, no reset occurs:

InitTarget() start
ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF
InitTarget() end - Took 101ms

(repeated 4 times, then:)

Connection failed.

Observation 2 — Board B, custom board, LPC5528, both Power Down and Deep Power Down

DM-AP IDCODE reads 0x00000000 on the first attempt, then a second attempt reports an explicit debug-mailbox recovery message and succeeds: 

InitTarget() start
ERROR: Wrong DM-AP IDCODE detected: 0x00000000
InitTarget() end - Took 101ms

ConfigTargetSettings() start
InitTarget() start
CPU halted successfully after enabling debug access
InitTarget() end - Took 7.40ms

Found SW-DP with ID 0x6BA02477
...
Connected to target device.

Observation 3 — NXP evaluation board, LPC55S28, both Power Down and Deep Power Down

DM-AP IDCODE also reads 0x00000000 on the first attempt, but the second attempt succeeds without printing the "enabling debug access" message — it just proceeds directly into a normal AP scan:

InitTarget() start
ERROR: Wrong DM-AP IDCODE detected: 0x00000000
InitTarget() end - Took 112ms

ConfigTargetSettings() start
InitTarget() start
InitTarget() end - Took 3.93ms

Found SW-DP with ID 0x6BA02477
Scanning AP map to find all available APs
AP[0]: AHB-AP (IDR: 0x84770001, ADDR: 0x00000000)
...
Connected to target device.

In all cases where the target is reachable at all, the device resets as an observable side effect of attaching, so device exits power down/deep power down.

Additional context

• The two custom boards are the same HW revision and run the same SW with the same Power Down/Deep Power Down configuration.
• For the evaluation board, we modified the example power_manager_lpc.c to use the same (or very similar) Power Down/Deep Power Down configuration as the custom boards.
• All devices can wake up on their configured wake-up sources, and all can connect to Ozone/the debugger normally while active (not in a reduced power mode).
• All boards are running the same SDK version (24.12.00).

Questions

1. Is a full chip reset always required to attach a debugger (SWD/Ozone/J-Link) to an LPC55S28 that's in Power Down or Deep Power Down? Or is there a supported way to inspect/halt the core without a reset in these modes?
2. What determines whether the DM-AP ID register reads 0xFFFFFFFF versus 0x00000000 when the target is asleep?
3. What's the difference between the debug-mailbox recovery path that reports "CPU halted successfully after enabling debug access" (Observation 2) versus the path that recovers silently with no such message (Observation 3)?
4. Is there a way to configure the device or the debug session so that attaching while the target is unreachable (asleep, DP truly unpowered) fails cleanly (as in Observation 1) rather than resetting the device, across all boards consistently — or is Observation 1 the anomaly and should not occur on healthy hardware?

Thanks in advance,

Paula

[luis_maravilla]

Hello

The debug mode is not supported in sleep, deep-sleep, power-down or deep-power down mode; This information is from LPC552x User Manual Chapter 13.3.1;

To attach a debugger to an LPC55S28 is necessary that you do the wake up first, using the reset if it was in a power down mode; and while the device is in this power down mode is not possible to attached the debug session;

The difference between whether the DM-AP ID register reads 0xFFFFFFFF versus 0x00000000 could be that 0x00000000 is a response that shows a command succeed return as mention in Table 1064 in UM11126 Chapter 50.5.7.2.1, and 0xFFFFFFFF is an not detected response.

The observation 1 seems weird, it could be a no response since the device could still be in a power down mode, or that you can't enter DM-AP correctly, therefore you can't debug; as an option you could consult if it's not a hardware issue with the board A, since the board B can be connected successfully.

Best Regards, Luis