KW45: Intermittent Wire ACK Fault During Programming/Debugging and Flash Erase Failure

[Prashanth1]

Hi Team,

I am currently working with a KW45-based custom board and facing an intermittent issue during programming and debugging the firmware.

I have tested the board with both a SEGGER J-Link and an NXP MCU-Link debug probe, and the issue occurs with both probes.

The custom board has the same boot configuration as the KW45 EVK, and the JTAG/SWD connections have also been checked and appear to be correct.

However, I am seeing the following behaviour:

When I try to dump or program a known-working application:

• Sometimes the application is programmed successfully, but after programming or starting a debug session, the device eventually jumps to a fault address.
• The debugger then halts at that location.
• During some programming or dumping attempts, I receive a Wire ACK fault.
• At other times, MCUXpresso reports:
  Error while executing the MI command
• I also tried to erase the flash from MCUXpresso, but the flash erase operation itself does not complete successfully.

Checks already performed

• JTAG/SWD connections have been checked and appear to be correct.
• The issue was tested with both a SEGGER J-Link and an NXP MCU-Link debug probe.
  Boot configuration has been compared with the KW45 EVK.
• I am using a known-working application for testing.
  The issue is intermittent: programming sometimes succeeds, but at other times a Wire ACK fault or MI command error occurs.
• Flash erase has also been attempted, but it does not complete successfully.

My questions

• What could cause the KW45 to: Intermittently report a Wire ACK fault while dumping or programming code?
• Report Error while executing the MI command?
• Jump or halt at an unexpected or invalid memory address after programming?
• Fail even when attempting a full flash erase?

Since the issue includes intermittent Wire ACK faults and failure during flash erase, I suspect this may be related to the debug interface, SWD/JTAG signal integrity, power-supply stability, reset sequence, flash controller state, device security/configuration, boot configuration, or another hardware-level issue rather than the application itself.

1. Could you please suggest the recommended procedure to:
2. Recover or erase the KW45 device.
3. Verify that the debug interface is functioning correctly.
4. Check whether the device is secured or in a state that prevents normal programming.
5. Determine whether the Wire ACK fault is caused by the target hardware, debug probe, power/reset behavior, or SWD/JTAG signal integrity.

I can provide the following information if required:

• MCUXpresso IDE version: 25.6.1
• Debug probes tested: SEGGER J-Link and NXP MCU-Link
• Complete error log, including the Wire ACK fault details
• Debug console output
• Schematic of the JTAG/SWD and boot connections
• SWD/JTAG clock frequency
• Power-supply and reset configuration
• Memory/register information from the failed state

Any guidance on the recommended troubleshooting steps would be greatly appreciated.

Thanks in advance.

[sofiaurueta]

Hello, hope you are doing well.

Firstly, could you please confirm some hardware details from your custom board:

Does the BOOT_CFG (PTA4) net have a pull-down resistor to GND? Are the VDD_SYS and VDD_CORE decoupling capacitors populated? As these are required to provide a feedback path and maintain voltage stability on the internal regulator output.

To attempt to recover the device, please try the following steps:

Are you able to access your device through ISP mode? For this, pull BOOT_CONFIG (PTA4) high during reset to force the device into ISP mode (on a KW47-EVK this is SW4)

Once in ISP mode, open a command prompt and run the following commands:

# Confirms ROM bootloader communication is working, a successful response confirms the device is reachable via ISP
blhost.exe -p COMX get-property 1
# Reveals whether the device is in OEM_OPEN or a secured lifecycle state
blhost.exe -p COMX get-property 07
# Perform a mass erase of the CM33 and NBU Program Flash
blhost.exe -p COMX flash-erase-all
blhost.exe -p COMX flash-erase-all 2

Afterwards, you could try running a hello_world or BLE example to make sure the board is working properly.

Also, just to confirm, which application did you run previously? Did you test with any low power examples? It is also possible that the device entered a low‑power state, disabling the SWD debug interface during low-power operation, which would prevent LinkServer or J-Link from connecting normally

Best regards,
Sofia.

[Prashanth1]

Hi Ma'am,

Thank you for your detailed response.

Regarding the hardware details:

• BOOT_CFG (PTA4) pull-down: Yes, the BOOT_CFG (PTA4) net has a pull-down resistor to GND on our custom board.

• VDD_SYS and VDD_CORE decoupling capacitors: Yes, the required decoupling capacitors are populated on the board. I have attached the relevant schematic sections/images showing the VDD_SYS and VDD_CORE connections and decoupling capacitors.

Meanwhile, I will proceed with the steps you suggested to access the device through ISP mode and will try the blhost commands to check the device state and perform the mass erase.

Regarding the application that was previously running:

The application is based on FreeRTOS and integrates the following peripherals/modules:

• FreeRTOS

• LPSPI0 with DMA

• GPIO

• LPSPI1 with FIFO

• WDOG

Regarding the low-power question, I did not intentionally use any specific low-power example in the application.

I will perform the ISP recovery procedure and let you know the results, particularly for:

• get-property 1

• get-property 07

• flash-erase-all

• flash-erase-all 2

Please let me know if there are any additional hardware checks or measurements you recommend while I perform these tests.

Prashanth1_0-1789454497591.pngPrashanth1_1-1789454501864.png

Thanks again for your support.

Best regards,
Prashanth