MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT 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: What conditions are required before AP0 and AP2 become accessible? Is DM-AP status 0x60F93638 associated with a known power, reset, or hardware configuration issue? Are there any known MCXN547 errata related to SWD or Debug Mailbox access? Which power and reset signals should we check for this symptom? MCXN Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT 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,
查看全文
