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. Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello @Rwaka, thank you for the information.
In order to better analyze the observed measurements, would you please share the schematic of your board?
Additionally, given that the measured resistance had a low value, would you please try adding an external pull-up resistor of a value between 10kΩ-100kΩ? As recommended in the following community post: Design Considerations for Debug.
Also, would you please share an oscilloscope capture of the observed reset signal at the RESET_b pin? Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello @RomanVR, Thank you for your support. Here are the measurements and details regarding our hardware setup: Circuitry on PTD0/RESET_b: The PTD0/RESET_b pin (pin 23) is routed directly to pin 10 of our 10-pin SWD debug header (FTSH-105). There are no external pull-up resistors or decoupling capacitors on this net on the PCB; it relies entirely on the MCU's internal pull-up. VDD_IO_D Rail Voltage: The rail measures 3.28V directly at the pin, which is well within the expected nominal voltage per AN14742. Resistance at RESET_b pin: With the board unpowered, I measured an abnormally low resistance of 38 Ohms to GND on the RESET pin. External reset test: I added an external 4.7 kOhm pull-up resistor to 3.3V on the reset line to test if it would bring the pin high. However, it had no effect and the SWD connection still fails, which aligns with the 38 Ohms impedance to GND completely overpowering the pull-up resistor. Given that this exact 38 Ohms near-short to GND is present on both of our factory-blank MCXW727CMFTBT units—whereas our MCXW716C variant works out of the box on the same PCB layout—could this indicate a silicon/fabrication defect on this lot (lot PF2R73.00), or is there an internal hardware condition that would pull this line low? Best regards, Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello again, Follow-up with the requested tests, all performed on our third, genuinely virgin unit (never powered/touched before this): External pull-up (10 kΩ, within your requested 10kΩ–100kΩ range): RESET_b, unpowered, with 10 kΩ pull-up in place: 16 kΩ (healthy — consistent with the internal ~313 kΩ measured in isolation, in parallel with our external 10 kΩ) RESET_b, as soon as the board is powered, same 10 kΩ pull-up still in place: collapses to 0.013 V SWD connect attempt (same setup): still fails identically — ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF Oscilloscope on RESET_b (PTD0) at power-up: not a hard flat line as we initially reported — closer inspection (1ms/div, 500mV/div) shows a genuine transient: the pin rises to approximately 1V (not 3.3V), holds that partial level for ~1ms with a slight upward ramp, then drops sharply back down and stays low. This same transient shape is present both with and without the external 10 kΩ pull-up, and was confirmed probing directly at the MCU pin (not just at the debug connector) — so it's a genuine signal at the pin, not a cable/connector artifact. Widening the timebase to 100ms/div and then 1s/div confirms this is a single, one-time event — no retries, no repeating cycle. This looks like the MCU making one failed/partial attempt to release RESET_b, then permanently stalling, rather than a repeating brownout/watchdog loop or the pin being held at a hard 0V from the very first instant. Oscilloscope on OSC1 output (pin 3, SIT8918BA active oscillator): clean 32.000 MHz square wave confirmed present and stable — so the main system clock reaching EXTAL is ruled out as a cause. Additional data point — official FRDM-MCXW72 board: using this exact same probe, we successfully connected to and flashed a genuine NXP FRDM-MCXW72 evaluation board without any issue. The MCU marking on this board reads: MCXW72 / 7CMFTB / 3P57K / S1953603 — confirming it's the same part number (MCXW727CMFTB) and same mask set (3P57K) as our failing custom-board units, just a different lot/date code (S1953603 vs. our PF2R73.00). This strongly confirms the probe/cable/tooling are not at fault, and points to something specific to lot PF2R73.00 rather than the part number or mask set in general. Summary: RESET_b is electrically healthy pre-power (313 kΩ isolated / 16 kΩ with external pull-up), the 32 MHz oscillator is running correctly, yet RESET_b collapses to near-0V the instant power is applied and stays there — even against a 10 kΩ external pull-up — with SWD permanently unable to connect, including with reset held (r/h/connect). This points to the MCU itself actively driving/holding RESET_b low very early in its boot sequence and never releasing it, rather than a passive/external electrical issue. Reproducible on a completely untouched unit, with a working FRDM-MCXW72 (same probe) as a positive control. Schematic excerpt (RESET_b / SWD header net, clock section) attached. Let us know what would help most next — happy to try SWDCLK/SWDIO scope captures during a connect attempt, or any other test. Best regards! Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello @Rwaka, thanks for performing the requested tests
Would you please share detailed pictures of your IC's? From both your custom boards and the used FRDM board.
Additionally, about your schematic, I'd suggest referring to AN14802 - Migration Guide from MCX W71 to MCX W72 and AN14742 - Power Management Hardware for the MCX W72 in order to ensure that proper power supply configurations were taken (e.g. rule out unsupported power mode implementations or power misconfigurations) and narrow down the observed behavior. Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello @Rwaka,
Could you please confirm which power configuration approach have you implemented in your design?
The previous question provides important context, given that, if you are using the "low-cost/bypass" supply configuration, it is recommended to leave DCDC_LX pin floating as stated in AN14742, if you have not implemented this supply configuration, the pin must not be left floating. Related to this topic, I'd suggest referring to Table 58. Recommended connection for unused interfaces of the MCXW72 Datasheet to ensure having a proper pin connection for your unused interfaces depending on your supply configuration. Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello, Went through AN14802/AN14742 against our schematic — one question before the IC pictures. DCDC_LX: left floating on our board (no external inductor), matching AN14742's "low-cost" config. But disabling the DC-DC requires a software write, which never happens on our blank/never-programmed units — so DC-DC stays at its hardware-default-enabled state with LX floating. Same exact layout is used on our working MCXW716C boards though. Could this (DC-DC enabled, LX floating) realistically block boot/SWD on a blank MCXW727C before any code runs? Would temporarily tying DCDC_LX to GND be a safe test, or should we avoid it (internal switch node, no inductor/snubbing)? IC pictures attached (custom board + FRDM board, chip markings). Best regards! Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello, To confirm: our board uses the "low-cost/bypass" supply configuration — no external DC-DC inductor, DCDC_LX left floating. We cross-checked against Table 58 (Datasheet) as suggested. Our layout matches the recommendations there for the DC-DC related pins: DCDC_LX: floating ✓ (matches "Float" recommendation) VSS_DCDC: tied to GND ✓ (matches "Always connect to VSS" recommendation) We didn't find a discrepancy on this specific section of the schematic. Let us know if there's another pin/area from Table 58 you'd like us to specifically re-check, or if you have another angle to investigate next. Best regards! Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello @Rwaka, thanks for cross-checking with the shared documentation.
Could you please share oscilloscope measurements of the signals at VDD_CORE/VOUT_CORE pins and at VDD_LDO_CORE pin?
Additionally, if you cannot share your full schematic, would you please refer to the following community post: The best way to build a PCB first time right with KW47 (Automotive) or MCX W72 (IoT/Industrial)? At the end of the post, the following two files are shared:
KW47 MCXW72 Design In checklist V3.xlsx: Checklist to determine if the design fully complies with the proper characteristics for the W72.
KW45 - MCX W71 - KW47 - MCX W72 Minimum BoM Presentation Customers May26.pdf: Guidance on the recommended external components and connections for your configuration (LDO Mode).
Please perform a crosscheck within the two specified files and let me know your findings. Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) Hello, We found it — thank you for the guidance that led us there! Root cause: VOUT_SYS/VDD_SYS (pin 22) had no decoupling capacitor at all on our custom board — completely floating, no connection whatsoever. Comparing against the official FRDM-MCXW72 schematic you pointed us to, that board decouples this pin with 4.7µF + 1.5µF + 0.1µF in parallel (R36/LDO_SYS_BYPASS is DNP there too, so VDD_SYS is purely internally-generated, just heavily decoupled). We added a single 4.7µF capacitor between VDD_SYS and GND on our third (previously untouched) unit — SWD connects immediately and flashing works. Interestingly, the exact same floating VDD_SYS (no cap at all) is present on our MCXW716C boards and those work fine — so this appears to be a real behavioral difference between the W71 and W72 power management block (possibly related to the new DC-DC ramp control feature mentioned in AN14664, which W71 doesn't have), rather than a documentation gap — Table 58 does list VDD_SYS as "floating except the decoupling capacitor," but doesn't specify a minimum value, and it's easy to miss how critical it apparently is on the W72 specifically. We'll add proper decoupling (matching your reference value) to VDD_SYS on our next board revision, and will also check our other two units (which additionally had a self-inflicted RESET_b anomaly from earlier testing, unrelated to this). Thank you very much for staying with us through this — the Table 58 / minimum BOM cross-check suggestion was exactly what we needed. Really appreciate the support. Best regards!
View full article
