2407772_en-US

[#1]

MCXW716C: ISP UART unresponsive despite confirmed ISP-mode entry via BOOT_CONFIG and SWD mailbox

Summary

I'm bringing up BLE on a custom board built around the MCXW716CMFTA (48-pin, not an NXP eval board). Before I can build/flash a BLE example, I need to update the NBU firmware (

mcxw71_nbu_ble_hosted.sb3

) via ISP, per the standard "Getting Started with FRDM-MCXW71" flow. The ISP UART interface (LPUART1) never responds to

blhost

, even though I have now confirmed — via two completely independent methods — that the chip does enter some kind of restricted/ISP-like state. I'd appreciate any insight into why the UART side stays silent, or whether there's a supported alternative path to write the NBU image.

Setup

Chip: MCXW716CMFTA (48-pin), custom PCB

SDK/tools: MCUXpresso Secure Provisioning Tool v25.06, SPSDK 3.0.1 (bundled

blhost

/

nxpdevscan

/

nxpdebugmbox

)

Debug probe: MCU-Link (PyOCD backend), connected via SWD on the board's J4 header — confirmed working for general debug access

USB-to-UART adapter: DSD TECH SH-U09C5 (genuine FTDI FT232RNL), set to 3.3V logic level

ISP pin mapping used (per AN14802 Table 7, confirmed identical for MCX W71/W72):

BOOT_CONFIG = PTA4

LPUART1 ISP RX = PTC2 (ALT3)

LPUART1 ISP TX = PTC3 (ALT3)

On the custom board these are accessible via test points TP7 (PTA4), TP26 (PTC2), TP43 (PTC3)

Symptom

blhost -p COMx -- get-property 1

(and the MCUXpresso Secure Provisioning Tool's own "Test connection") always fails:

SpsdkNoDeviceFoundError: No devices for given interface 'uart' and parameters 'port=COM5, timeout=5000' was found.

​

nxpdevscan -vv

shows the mboot ping bytes

[0x5A, 0xA6]

being sent 3 times, each followed by

SPSDKTimeoutError

, then a fallback to the SDP

ReadStatus

command, which also times out (

SdpConnectionError

). No response is ever received from the target.

What I've already ruled out

Wiring polarity (tried both orientations)

Voltage levels: TP7, TP26, TP43 all measure 3.3V steady-state

Adapter/driver: genuine FTDI, confirmed "working properly" in Device Manager, COM port exists

Flow control (confirmed NONE via a loopback test)

Port locking by another application

A real hardware defect: PTC3 (net "WPT2_Drive_EN") was directly loaded via a 0-ohm resistor to the EN pin of an LTC7068 DC/DC controller used for our wireless-power-transfer coil driver. This pulled TP43's idle-high level down to ~2.3V. I removed this resistor and confirmed TP43 now idles correctly at 3.3V — this was a real bug, but it did not resolve the ISP communication failure.

Loading on the PTC2 net (shared with a "POWER_SW" button input on our board): traced the schematic, confirmed no pull-up/pull-down/RC filtering on this net.

Physical confirmation that the PC→board direction works

The USB adapter has built-in TX/RX activity LEDs. During a

blhost get-property

attempt:

TXD LED blinks 3 times, matching the 3 ping retries seen in

nxpdevscan -vv

— confirming the PC genuinely transmits.

RXD LED never lights, confirming the board never transmits anything back.

An oscilloscope capture on TP26 (PTC2) during the same test shows a waveform whose total duration (~350µs) matches the expected timing of two back-to-back UART bytes at 57600 baud, consistent with the ping bytes actually reaching the pin electrically.

New finding: ISP-mode entry succeeds via two independent methods, but UART is dead in both cases

Using

nxpdebugmbox

(SWD via the same MCU-Link probe), I tested two completely separate ways of entering ISP mode:

Method A — physical BOOT_CONFIG pin: Full power cycle (USB fully unplugged/replugged) with TP7 (PTA4) jumpered to VDD through the power-up moment.

Method B — SWD/Debug Mailbox, no pin strapping at all:

nxpdebugmbox -i pyocd cmd -f mcxw716c start nxpdebugmbox -i pyocd cmd -f mcxw716c ispmode -m 1

​

Both commands report success ("Start Debug Mailbox succeeded" / "Entering into ISP mode succeeded").

In both cases, immediately afterward,

blhost -p COMx -- get-property 1

still returns

SpsdkNoDeviceFoundError

— zero response on UART either way.

Also worth noting:

nxpdebugmbox mem-tool test-connection -d debug_port

succeeds in both normal boot and BOOT_CONFIG-held states. But

mem-tool read-memory -a 0x0 -c 16

succeeds during normal boot (returns the application's vector table) and fails with

SPSDK: The memory access port is not found!

while BOOT_CONFIG is held — so something about the chip's debug/memory access configuration does change when BOOT_CONFIG is asserted, even though it doesn't explain why UART stays silent.

Questions

Given that ISP-mode entry is confirmed successful via both the BOOT_CONFIG pin and the SWD Debug Mailbox

ispmode

command, is there a known reason the LPUART1 ISP interface (PTC2/PTC3, ALT3) would still not respond to the standard mboot ping?

Are there additional preconditions for the UART ISP interface to become active (clock configuration, chip revision–specific behavior, life-cycle-state restrictions) that aren't covered in AN14648/AN14802?

As an alternative: since SWD/Debug Mailbox communication is fully functional (

test-connection

and

read-memory

succeed during normal operation), is there a supported way to write the NBU firmware (

mcxw71_nbu_ble_hosted.sb3

, targeting

radio_flash

at 0x48800000) via SWD/Debug Mailbox instead of UART ISP? The MCUXpresso Secure Provisioning Tool's target definition for MCXW716C lists only

"connections": ["uart"]

— is SWD-based provisioning of

radio_flash

possible through

nxpdebugmbox

/

nxpimage

, and if so, what's the procedure?

Any pointers — including "here's the actual root cause of X" or "here's how to flash NBU over SWD instead" — would be hugely appreciated. Happy to provide additional logs/scope captures if useful.

Re: MCXW716C: ISP UART unresponsive despite confirmed ISP-mode entry via BOOT_CONFIG and SWD mailbox

Hi @chocola_saka, hope you are doing well.

Would you please clarify if you have already burned any set of fuses? If so, please specify which. This is important since fuse 17 has the capability to disable ISP path.

Additionally, please specify if you have written any configuration to sector 0 of IFR before this behavior started to appear, as this sector is dedicated to ROM boot and ISP configurations.

Were you able to previously load the NBU to your board?

Also, regarding your question about loading the NBU through SWD, I'd suggest referring to AN14397 - Programming the MCXW71 Flash for Application and Radio Firmware via Serial Wire Debug Duri.... It provides a guide to merge an application binary to the NBU firmware and load the final binary through SWD.

Please let me know the requested information and if the resource shared is helpful.