MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT

[george_from_hyn]

Hello NXP Support,

We are using an MCXN547VKLT on a custom board with an external MCU-Link probe.

The SWD connection fails when starting a debug session:

Ee(42). Could not connect to core.
Et:31: No connection to chip's debug port.
Remote connection closed.

The SWD-DP can be detected correctly:

DPID = 0x6BA02477

However, access to CPU0 AHB-AP (AP0) fails with:

WIRE ACK FAULT

The Debug Mailbox request also fails. LinkServer reports:

DM-AP status: 60F93638
DM-AP: AHB_OR_ERR
DM-AP: DBG_OR_ERR

What we have checked:

• SWD frequency tested from 1 MHz down to 10 kHz
• SWDIO and SWCLK waveforms look good on an oscilloscope
• VDD_CORE = 1.2 V
• VDD_SYS = 1.8 V
• VDD_DCDC and I/O supplies = 3.3 V
• RESET_B works correctly
• MCU-Link firmware: CMSIS-DAP V3.172
• LinkServer version: 26.5.59
• The same MCU-Link works with an MCXN947 development board
• The MCXN547 was replaced with a new chip, but the problem remains

USB ISP works correctly with VID/PID 1FC9:014F. Using blhost, we can:

• Erase internal Flash
• Program and read internal Flash
• Run the application successfully
• Enumerate the application USB composite device

The ROM reports:

Security State = UNSECURE

We also read the PFR through USB ISP:

• CMPA is completely erased (0xFF)
• CFPA is erased except for the ROM-generated CMAC
• No customer SOCU or Debug Authentication configuration is present

Could you please advise:

1. What conditions are required before AP0 and AP2 become accessible?
2. Is DM-AP status 0x60F93638 associated with a known power, reset, or hardware configuration issue?
3. Are there any known MCXN547 errata related to SWD or Debug Mailbox access?
4. Which power and reset signals should we check for this symptom?

[SofiaIdris]

This is a tough one! Debugging connection issues can be really frustrating, especially with custom boards. That "WIRE ACK FAULT" definitely points to a communication breakdown. Have you had any luck trying different SWD clock speeds, or perhaps checking the power supply to the MCU during the debug session? Sometimes a marginal power delivery can cause these kinds of intermittent failures. It reminds me a bit of trying to get a perfect run in Snow Rider 3D – one small misstep can throw everything off! I hope you get to the bottom of it soon!

[george_from_hyn]

Hello Luis,

We have now been able to establish an SWD debug connection by using the SPSDK Debug Mailbox tool.

The procedure we used is as follows:

1. Reset the MCU through the Debug Mailbox:

nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \
-o enable_recovery_reset=True \
--operation-timeout 5000 \
tool reset -f mcxn547

2. Start a debug session through the Debug Mailbox:

nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \
-o enable_recovery_reset=True \
--operation-timeout 5000 \
cmd -f mcxn547 start-debug-session

3. After the debug session has been opened, we connect to the Cortex-M33 core with LinkServer over SWD.

We did not use any authentication keys, passwords, debug credentials, or mass erase commands. It appears that the "start-debug-session" command temporarily enables AP0 through the always-accessible AP2 Debug Mailbox.

We also used the GDET register sequence from the NXP LS_preconnect_MCXN5XX.scp script after opening the debug session. The sequence disables the aGDET and dGDET reset routing and disables SPC glitch detection during debugging.

Regarding the power supplies:

- VDD_VBAT is directly connected to VDD, and both are 3.3 V.
- VDD_P4 is directly connected to VDD, and both are 3.3 V.
- VDD_ANA is connected to VDD through a ferrite bead.
- VDD is 3.3 V.

However, we now have another debugging problem.

When the board is powered on normally without an SWD debug reset, the firmware runs correctly. However, when we enter the debug session using the Debug Mailbox reset procedure described above, the firmware does not start correctly.

The debug connection is lost when single-stepping through the following SDK function:

static inline void SPC_SetActiveModeDCDCRegulatorVoltageLevel(
SPC_Type *base,
spc_dcdc_voltage_level_t voltageLevel)
{
base->ACTIVE_CFG =
(base->ACTIVE_CFG & (~SPC_ACTIVE_CFG_DCDC_VDD_LVL_MASK)) |
SPC_ACTIVE_CFG_DCDC_VDD_LVL(voltageLevel);
}

More specifically, the connection is lost when ACTIVE_CFG is written to change the active-mode DCDC voltage level.

The behavior is therefore different between the following two cases:

1. Cold power-on:
The firmware starts and runs normally.

2. Debug Mailbox reset followed by start-debug-session and SWD connection:
The firmware reaches the SPC DCDC configuration, but the debugger loses the target when ACTIVE_CFG is written, and the application cannot start normally.

Could the Debug Mailbox reset leave the SPC, DCDC, GDET, or reset status in a different state compared with a full power-on reset?

Is there a required sequence before modifying SPC ACTIVE_CFG after starting a Debug Mailbox debug session? For example:

- waiting for SPC_SC[BUSY] to clear;
- clearing an SPC or GDET status flag;
- unlocking or disabling glitch detection;
- using a specific reset type;
- avoiding a soft reset after start-debug-session;
- or applying the complete LS_preconnect_MCXN5XX.scp sequence?

Could writing the DCDC voltage level while debugging trigger a GDET event, DCDC protection event, brownout reset, or another system reset?

Please also advise which registers we should capture immediately before the ACTIVE_CFG write. We can provide values for registers such as SPC_SC, SPC_CNTRL, SPC_ACTIVE_CFG, SPC_GLITCH_DETECT_SC, CMC_SRS, CMC_SSRS, and the Debug Mailbox CSW.

Best Regards,

[luis_maravilla]

Hello,

AP2 (DBGMB) Debug access port for debug mailbox is always enabled, and the external world can send data to and receive data from ROM.

AP0 has security controls

Could you help us confirm if you have used keys for authentication?

This is represented in figure 1 in MCX Nx4x Debug Authentication [AN14162]

When you mentioned

DM-AP status: 60F93638
DM-AP: AHB_OR_ERR
DM-AP: DBG_OR_ERR

It could refer to Command and Status Word (CSW) and it's indicating that an AHB Overrun and/or a DBGMB Overrun occur; as the Chapter 10.3.2.4 (SRM) mentioned that an error flag in this prevents communication and need to request to clear the error flag.

Could you share the values in CSW register

For more information on this please refer to the MCX N Security Reference Manual Chapter 10.5.1.2

There are no errata on this; The information that could help you with the SWD is the Application Note MCX Nx4x Debug Authentication[AN14162] and the Debug Mailbox Chapter 10 in MCX N Security Reference Manual

Power and reset signals you could check are the one you mention and additionally VDD_P4, VDD_VBAT, and VDD_ANA and the POR Sequence.

Could you confirm if you are following the Required Power On reset sequencing?

MCX N 547 Datasheet Chapter 2.

Best Regards, Luis