2411742_en-US

はい

MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure)

We cannot establish an SWD debug connection to any of our MCXW727CMFTBT samples (2 units, custom board), while the exact same probe/cable/setup connects immediately to an MCXW716C on an otherwise identical board (same schematic, same BOM, only the MCU differs).

Part: MCXW727CMFTBT, HVQFN-48, date code 9D2604, lot PF2R73.00 Boards: custom PCB (10-pin Cortex Debug SWD, no ISP button), factory-blank/never-programmed SDK: MCUXpresso SDK 26.06.00 — application builds/links fine, failure is purely at debug-connect stage

Symptom

Fails identically with both NXP LinkServer 25.12.83 and a genuine SEGGER J-Link Plus:

LinkServer:  Error: Wire Ack Fault - target connected?
             Ed:02: Failed on connect: Ee(42). No connection to chip's debug port
J-Link:      device MCXW727C_M33_0 / connect (VTref correctly read at 3.025V)
             ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF

LinkServer's own MCXW7XX pre-connect script (LS_preconnect_MCXW7XX.scp) does issue a Debug Session Request automatically — still fails. nxpdebugmbox (SPSDK) manual Start Debug Session also fails with the same WIRE ACK FAULT.

Already ruled out

Probe/cable/adapter: confirmed working (same setup connects fine to MCXW716C)
VDD_IO / P3V3 at the MCU: ~3.3V, correct
SWDIO/SWDCLK continuity: good
VDD_CORE (internal LDO): 1.065V, in range
RESET_b at rest, cable unplugged: reads 0V instead of expected internal-pull-up ~3.3V (Ref. Manual §22.3.1) — on both units
RESET_b forced externally to 3.3V during connect attempt (with VTref correctly read at 3.025V): no change, still fails with the same Wrong DM-AP IDCODE 0xFFFFFFFF
Reproducible on 2 separate physical units / 2 separate boards

Related thread

Same exact error (Wrong DM-AP IDCODE 0xFFFFFFFF) reported here on the same device name, though in a different scenario (board worked, then broke after an erase/reprogram cycle): FRDM-MCXW72 no longer connects. Our units have never been flashed at all, so if there's a link to NBU/core state as that thread suggests, it apparently can also affect units that were never touched by the customer.

Questions

Any known erratum / boot-config requirement / default life-cycle state for early-production MCXW727CMFTBT (lot PF2R73.00) that would block SWD on a blank device beyond the standard Debug Mailbox procedure?
RESET_b reading 0V at rest (contrary to documented internal pull-up) on both units — fabrication issue with this lot, or something else expected to drive this pin at POR?
Recommended recovery procedure for this exact case that doesn't require UART-based ISP (our board has no on-board USB-UART bridge)?

Happy to provide full logs, oscilloscope captures, or anything else useful on request.

Protocol: BLE -> connectivity

Protocol: Thread

Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure)

Thank you for the quick follow-up!

To clarify, we tested with both probes, each with its own appropriate tool — not mixing LinkServer with the J-Link probe:

NXP MCU-Link Pro, accessed through LinkServer 25.12.83, via the MCUXpresso for VS Code debug/flash integration (which launches LinkServer's gdbserver/flash-programmer under the hood). This is our normal day-to-day setup.
- Result: Wire Ack Fault - target connected? / Ed:02: Failed on connect: Ee(42). No connection to chip's debug port, including when LinkServer automatically runs its MCXW7XX-specific pre-connect script (LS_preconnect_MCXW7XX.scp, which issues a Debug Session Request).
A separate, genuine SEGGER J-Link Plus (firmware V11.00) + J-Link Adapter CortexM (20-pin → 10-pin 0.05"), accessed through J-Link Commander V9.74 directly (not through LinkServer).
- Result: ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF on connect, with VTref correctly read at 3.025 V.

We ran this second test specifically to rule out any LinkServer/MCU-Link-specific issue. Using this exact same J-Link Plus + adapter + cable + lab power supply setup, swapping only the target board for our MCXW716C variant (identical PCB, only the MCU differs), J-Link Commander connects successfully and identifies the Cortex-M33 core — so the probe, cable, adapter, and tool are confirmed working correctly; the failure appears specific to the MCXW727C part/board.

We have not yet tried J-Flash or LinkFlash specifically, only J-Link Commander (connect) and LinkServer's built-in "debug" and "resurrect" flash-programmer modes — happy to try either of those if it would help narrow this down further.

Let us know if there's any additional information or logs that would be useful.

Best regards!

Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure)

Hello @Rwaka, hope you are doing well.

In order to better understand the behavior you are observing, would you please confirm if for each case you are using an external J-Link debugger? Or have you tried also with an MCU-Link Pro?

Additionally, please provide which tool (LinkFlash, J-Flash, J-Link Commander) you are using to access through SWD, as Linkserver is a utility for launching and managing GDB servers for NXP debug probes (e.g. MCU-Link Pro), therefore it is expected that a J-Link probe will not be detected by Linkserver. While the J-Link Plus probe will only be detected and usable along J-Link Commander/J-Flash tools.

Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure)

Hello @Rwaka, thank you for providing additional information.

I noticed that you mentioned that your Reset_b signal was reading 0V, this means that the device is in a constant reset state. Given this, I will ask some questions that will help to further analyze the observed behavior:

Would you please clarify if there is any connected hardware/circuitry to the PTD0/RESET_b pin of the MCU? Is it floating?
Is the VDD_IO_D rail measuring the proper voltage? Since this power domain drives voltage on the reset system. You may refer to AN14742 for reference on the power management hardware recommendations.
Are you able to measure any resistance at RESET_b pin? If so, please provide the measured value.
When you performed the forced reset externally, did you connect the external voltage directly to the reset pin?

Please let me know the requested information.