OM40002 - Unable to program/debug to LPC8N04

epi_lg · ‎06-26-2025

Hi all,

I'm currently working with the OM40002 dev board and it worked fine in the beginning. But after I flashed a new firmware onto it, the on-board debugger wasn't able to connect to the LPC8N04 anymore.
Here is the console output:

Executing flash operation 'Erase' (Erase flash) - Thu Jun 26 12:05:23 CEST 2025
Checking MCU info...
Scanning for targets...
Executing flash action...
LinkServer RedlinkMulti Driver v24.12 (Dec 18 2024 18:34:07 - crt_emu_cm_redlink.exe build 869)
( 0) Reading remote configuration
Wc(03). No cache support.
Found chip XML file in <path to LPC8N04.xml>\LPC8N04.xml
( 5) Remote configuration complete
Reconnected to existing LinkServer process.
============= SCRIPT: lpc8n04connect.scp =============
DpID = 0BC11477
Reset pin state: 01
DpID = 0BC11477
APID = 0x04770031
============= END SCRIPT =============================
Probe Firmware: LPC11U3x CMSIS-DAP v1.0.7 (NXP Semiconductors)
Serial Number: 01014009
VID:PID: 1FC9:0132
USB Path: \\?\hid#vid_1fc9&pid_0132&mi_00#9&819ceb&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Using memory from core 0 after searching for a good core
On debug connection - reset using system reset
( 30) Emulator Connected
( 40) Debug Halt
( 50) CPU ID
debug interface type = CoreSight DP (DAP DP ID 0BC11477) over SWD TAP 0
processor type = Cortex-M0+ (CPU ID 00000C60) on DAP AP 0
number of h/w breakpoints = 4
number of flash patches = 0
number of h/w watchpoints = 2
Probe(0): Connected&Reset. DpID: 0BC11477. CpuID: 00000C60. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Enabled.
Content of CoreSight Debug ROM(s):
RBASE E00FF000: CID B105100D PID 04000BB4C0 ROM (type 0x1)
ROM 1 E000E000: CID B105E00D PID 04000BB008 Gen SCS (type 0x0)
ROM 1 E0001000: CID B105E00D PID 04000BB00A Gen DWT (type 0x0)
ROM 1 E0002000: CID B105E00D PID 04000BB00B Gen FPB (type 0x0)
NXP: LPC8N04
DAP stride is 1024 bytes (256 words)
Inspected v.2 On-chip Flash Memory LPC8N0x_30K.cfx
Image 'LPC8N0x (30K) Dec 18 2024 17:28:00'
( 65) Chip Setup Complete
Connected: was_reset=false. was_stopped=true
( 70) License Check Complete
Opening flash driver LPC8N0x_30K.cfx
Sending SYSRESETREQ to run flash driver
request to clear DAP error failed - status 5
After error Nn(05). Wire ACK Fault in DAP access -
Failed to read address register in DAP - Nn(05). Wire ACK Fault in DAP access
Failed to erase flash: Em(17). Debug port inaccessible after access at location 0x10000000
(100) Target Operation Failed
request to clear DAP error failed - status 5
request to clear DAP error failed - status 5
error closing down debug session - Nn(05). Wire ACK Fault in DAP access
Unable to perform operation!
Command failed with exit code 1

I searched for a while in hope to find a solution for that problem.
There are a couple of posts about the low-power mode and it's consequences. The firmware is not using the deep-power-down mode but the stop mode, so I don't think thats the problem. I anyway tried to setup a connection while having an active NFC field around the mcu as suggested. That did changed nothing.

Other posts meantioned problems due to the lack of proper pin configurations (SWD pins not configured). I used the MCUXpresso IDE's pin configurator to setup the SWCLK/SWDIO pins (among other), so I dont expect that to be the problem, either.

I also tried to use another debugger/programmer. I tried to use a ST-Link V2 with openOCD. I used stlink.cfg for the interface configuration and lpc8nxx.cfg for the target.

The naive approach of just running "reset init" or "reset halt" resulted in the following error message:

timed out while waiting for target halted
TARGET: lpc8nxx.cpu - Not halted

Using "reset_config srst_only" (as suggested in lpc8nxx.cfg) resulted in:

jtag status contains invalid mode value - communication failure
Polling target lpc8nxx.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Previous state query failed, trying to reconnect

Right before I lost my ability to debug and program the mcu I had debugged it and it ran into a hard fault more or less right after the board init functions. I don't if this could maybe could cause this problem.

I'm running out of ideas how to possibly regain control over that chip. If someone have an idea of how to de-brick that mcu, I would love to hear that.

Daniel_Gutierrez · ‎06-27-2025

Hello @epi_lg, Good Day!

Thank you very much for your interest in our products.

I would like to ask what is the firmware you are trying to flash onto the chip? Have you downloaded the LPC8N04DevBoard SDK package available at MCUXpresso SDK Builder?

I would also like to ask if the firmware you were able to previously flash was part of the SDK package? And lastly, what is the MCUxpresso IDE version that you are using?

Please consider that for being able to debug the chip using the onboard debugger, a specific jumper configuration on the board has to take place. Please refer to section 3 of the User Manual for LPC8N04 Development Board and ensure that this configuration takes place, as well as the steps mentioned in the document for being able to flash an application onto the LPC8N04.

My best regards,
Daniel

epi_lg · ‎06-27-2025

Hi @Daniel_Gutierrez ,

thank you for your reply.

I was working on an custom application. Nothing too crazy, NFC, SPI and a couple of GPIOs are planned to be used there. For that I used the drivers included in the SDK.

I have 2 installed SDKs:

SD_2.x_LPC8N04 (SDK Version 2.8.0, Manifest 3.6.0)
SD_2.x_LPC8N04DevBoard (SDK Version 2.8.0, Manifest 3.6.0)

The last firmware I was able to flash is my custom firmware. It crashed because I probably used the CTIMER driver incorrectly which resulted into a hardfault. After that, I wasn't able to connect to the device anymore.

I'm currently using the MCUXpresso IDE version 24.12 (Build 148).

I used the onboard debugger for flashing and debugging. When that stopped working I tried the other debugger, which also not worked.

The jumper for P7 and P8 are set as shown in UM11082. Because that worked before I'm sure that this configuration is correct.

I retried to flash the board today and a SWD Configuration error message appeared. "0 available SWD Devices detected".

I added the .mex file of that application as an attachement.

Thank you and kind regards,

Lars

Daniel_Gutierrez · ‎06-30-2025

Hello @epi_lg, Good Day!

Please make sure that jumper P1 is not inserted since this would hold the onboard debug probe in reset.

In order to troubleshoot I would like to ask if you could please try updating the debugger firmware by following the steps described in section 3.4 of the UM11082 document.

Please let me know your findings.

My best regards,
Daniel

epi_lg · ‎06-30-2025

Hi @Daniel_Gutierrez,

I upgraded the Debugger's firmware as descriped. This worked without any problems and the device is recognized by my OS as expected.

I then went on trying to flash one of the SDK examples (ndeft2t_hello).

Its build process went fine except for an popup telling me that GCC "does not allow the inclusion of non-freestanding library headers" when using the -ffreestanding parameter. It still was able to compile.

Unfortunataly, flashing the device still didn't work. Output:

LinkServer RedlinkMulti Driver v24.12 (Dec 18 2024 18:34:07 - crt_emu_cm_redlink build 869)

Found chip XML file in <Project Path>/lpc8n04devboard_ndeft2t_hello/Debug\LPC8N04.xml

Reconnected to existing LinkServer process.

Connecting to probe 1 core 0 (using server started externally) reports:

'Ee(42). Could not connect to core.'

Retrying...

Reconnected to existing LinkServer process.

Server OK but no connection to probe 1 core 0 (after 3 attempts) - Ee(42). Could not connect to core.

============= SCRIPT: lpc8n04connect.scp =============

DpID = 0BC11477

Reset pin state: 01

DpID = 0BC11477

APID = 0x04770031

============= END SCRIPT =============================

Probe Firmware: LPC11U3x CMSIS-DAP v1.0.7 (NXP Semiconductors)

Serial Number: 01014009

VID:PID: 1FC9:0132

USB Path: \\?\hid#vid_1fc9&pid_0132&mi_00#9&819ceb&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}

Using memory from core 0 after searching for a good core

debug interface type = CoreSight DP (DAP DP ID 0BC11477) over SWD TAP 0

processor type = Cortex-M0+ (CPU ID 00000C60) on DAP AP 0

number of h/w breakpoints = 4

number of flash patches = 0

number of h/w watchpoints = 2

Probe(0): Connected&Reset. DpID: 0BC11477. CpuID: 00000C60. Info: <None>

Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.

Content of CoreSight Debug ROM(s):

RBASE E00FF000: CID B105100D PID 04000BB4C0 ROM (type 0x1)

ROM 1 E000E000: CID B105E00D PID 04000BB008 Gen SCS (type 0x0)

ROM 1 E0001000: CID B105E00D PID 04000BB00A Gen DWT (type 0x0)

ROM 1 E0002000: CID B105E00D PID 04000BB00B Gen FPB (type 0x0)

NXP: LPC8N04

DAP stride is 1024 bytes (256 words)

Inspected v.2 On-chip Flash Memory LPC8N0x_30K.cfx

Image 'LPC8N0x (30K) Dec 18 2024 17:28:00'

Connected: was_reset=true. was_stopped=true

Awaiting telnet connection to port 3330 ...

GDB nonstop mode enabled

Opening flash driver LPC8N0x_30K.cfx

request to clear DAP error failed - status 5

Target error from Commit Flash write: Nn(05). Wire ACK Fault in DAP access

GDB stub (D:\nxp\LinkServer_24.12.21\binaries\crt_emu_cm_redlink) terminating - GDB protocol problem: Pipe has been closed by GDB.

invalid server read transfer - expect: 9, actual: 1

invalid server read transfer - expect: 10, actual: 2

invalid server read transfer - expect: 11, actual: 3

error closing down debug session - Ee(47). Invalid Transfer

The jumper on P7 and P8 are still set for SWD.

I also retried the debugging process with an active NFC filed next to the LPC8N04. The result was the same.

Kind regards,

Lars

Daniel_Gutierrez · ‎07-03-2025

Hello @epi_lg, Good Day!

I would like to ask if you could please share a picture of the setup of your board in which the jumpers of all the board can be appreciated.

Could you please confirm that the debug probe is being detected by MCUXpresso as follows?

If the probe is being detected, could please try performing a Mass erase of the chip using the GUI Flash Tool of the IDE?

In this window select Mass erase and click on Run.

Please let me know your findings.

My best regards,
Daniel

epi_lg · ‎07-04-2025

Hi @Daniel_Gutierrez,

Here is an image of the jumper configurations.

OM40002 HW Config

MCUXpresso does recognize the onboard debug probe.

Discovered Probes

Unfortunately, the flash erase failed with the following console output:

Executing flash operation 'Erase' (Erase flash) - Fri Jul 04 09:15:21 CEST 2025

Checking MCU info...

Scanning for targets...

Executing flash action...

LinkServer RedlinkMulti Driver v24.12 (Dec 18 2024 18:34:07 - crt_emu_cm_redlink.exe build 869)

( 0) Reading remote configuration

Wc(03). No cache support.

Found chip XML file in D:/projects/nfcDisplay/Firmware/lpc8n04devboard_ndeft2t_hello/Debug\LPC8N04.xml

( 5) Remote configuration complete

Reconnected to existing LinkServer process.

Connecting to probe 1 core 0 (using server started externally) reports:

'Ee(42). Could not connect to core.'

Retrying...

Reconnected to existing LinkServer process.

Server OK but no connection to probe 1 core 0 (after 3 attempts) - Ee(42). Could not connect to core.

============= SCRIPT: lpc8n04connect.scp =============

DpID = 0BC11477

Reset pin state: 01

DpID = 0BC11477

APID = 0x04770031

============= END SCRIPT =============================

Probe Firmware: LPC11U3x CMSIS-DAP v1.0.4 (NXP Semiconductors)

Serial Number: 15044027

VID:PID: 1FC9:0132

USB Path: \\?\hid#vid_1fc9&pid_0132&mi_00#9&d122a&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}

Using memory from core 0 after searching for a good core

( 30) Emulator Connected

( 40) Debug Halt

( 50) CPU ID

debug interface type = CoreSight DP (DAP DP ID 0BC11477) over SWD TAP 0

processor type = Cortex-M0+ (CPU ID 00000C60) on DAP AP 0

number of h/w breakpoints = 4

number of flash patches = 0

number of h/w watchpoints = 2

Probe(0): Connected&Reset. DpID: 0BC11477. CpuID: 00000C60. Info: <None>

Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.

Content of CoreSight Debug ROM(s):

RBASE E00FF000: CID B105100D PID 04000BB4C0 ROM (type 0x1)

ROM 1 E000E000: CID B105E00D PID 04000BB008 Gen SCS (type 0x0)

ROM 1 E0001000: CID B105E00D PID 04000BB00A Gen DWT (type 0x0)

ROM 1 E0002000: CID B105E00D PID 04000BB00B Gen FPB (type 0x0)

NXP: LPC8N04

DAP stride is 1024 bytes (256 words)

Inspected v.2 On-chip Flash Memory LPC8N0x_30K.cfx

Image 'LPC8N0x (30K) Dec 18 2024 17:28:00'

( 65) Chip Setup Complete

Connected: was_reset=true. was_stopped=true

( 70) License Check Complete

Opening flash driver LPC8N0x_30K.cfx

Sending SYSRESETREQ to run flash driver

request to clear DAP error failed - status 5

After error Nn(05). Wire ACK Fault in DAP access -

Failed to read address register in DAP - Nn(05). Wire ACK Fault in DAP access

Failed to erase flash: Em(17). Debug port inaccessible after access at location 0x10000000

(100) Target Operation Failed

request to clear DAP error failed - status 5

error closing down debug session - Nn(05). Wire ACK Fault in DAP access

Unable to perform operation!

Command failed with exit code 1

Kind regards,

Lars

Daniel_Gutierrez · ‎07-10-2025

Hello @epi_lg

In the past few days, I have been running tests on the OM40002 revision A board and have found that this is a recurrent problem with the chip, unfortunately the concrete cause of failure is unknown, however the issue may be caused by the chip entering deep power-down mode where the core becomes unavailable or an unknown state.

This is particularly difficult to solve since, given this is a very old chip, it does not support ISP mode as most newer MCU's. However, if by any chance in the firmware you loaded previously you configured the PIO0_0 to work as a wake-up pin, you could try to use this to be able to flash it, as described in Table 3. of the LPC8N04 Data Sheet.

My best regards,
Daniel

epi_lg · ‎07-14-2025

Hi @Daniel_Gutierrez,

Thank you very much for your efforts. Unfortunately, I'm still not able to bring that chip back to life.

I tried to use PIO0_0 before and during the LinkServer connection without any luck.

I also tried the same with Reset. That, sometimes if I press the button in a perfect moment during LinkServer connection seems to work at first.

Without doing this the LinkServer process reports the problem 'Ee(42). Could not connect to core.':

....
( 5) Remote configuration complete
Reconnected to existing LinkServer process.
Connecting to probe 1 core 0 (using server started externally) reports:
'Ee(42). Could not connect to core.'
Retrying...
Reconnected to existing LinkServer process.
Server OK but no connection to probe 1 core 0 (after 3 attempts) - Ee(42). Could not connect to core.
...
Opening flash driver LPC8N0x_30K.cfx
Sending SYSRESETREQ to run flash driver
request to clear DAP error failed - status 5
After error Nn(05). Wire ACK Fault in DAP access -
Failed to read address register in DAP - Nn(05). Wire ACK Fault in DAP access
Failed to erase flash: Em(17). Debug port inaccessible after access at location 0x10000000
(100) Target Operation Failed
...

By spamming the Reset button and a little bit of luck the first error disapears:

...
( 5) Remote configuration complete
Reconnected to existing LinkServer process.
============= SCRIPT: lpc8n04connect.scp =============
DpID = 0BC11477
Reset pin state: 01
DpID = 0BC11477
APID = 0x04770031
============= END SCRIPT =============================
Probe Firmware: LPC11U3x CMSIS-DAP v1.0.7 (NXP Semiconductors)
Serial Number: 01014009
VID:PID: 1FC9:0132
USB Path: \\?\hid#vid_1fc9&pid_0132&mi_00#9&819ceb&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
...
Opening flash driver LPC8N0x_30K.cfx
Sending SYSRESETREQ to run flash driver
request to clear DAP error failed - status 5
After error Nn(05). Wire ACK Fault in DAP access -
Failed to read address register in DAP - Nn(05). Wire ACK Fault in DAP access
Failed to erase flash: Em(17). Debug port inaccessible after access at location 0x10000000
(100) Target Operation Failed
....

Nevertheless, the actual command (flash erase in this case) then fails.

You meantioned the lack of functionalities which would help here and exists in newer chips. Is there maybe a successor chip with comparible functionalities (NFC, Low Power, Low Cost) that I could use instead?

Thank you and kind regards,

Lars

Daniel_Gutierrez · ‎07-16-2025

Hello @epi_lg, Good Day!

An alternative to the LPC8N04 could be the NHS3152 which includes similar features, such as the same NFC/RFID ISO 14443 type A interface as the LPC8N04 and the same reduced power modes (Sleep, Deep-sleep and Deep power-down and Battery-off). Opposite to the LPC it does not support SPI communication.

The debugging issue you experienced with the LPC8N04 can happen as well with this chip, as it includes the same reduced power modes, however, in the NHS3152 documentation you will find a series of proved to work solutions in case this happens again, as well as guidelines to follow in order to prevent this problem when implementing your application.

The NHS3152 SDK includes as well macros that can be defined in the implemented application to avoid entirely entering these power modes, as well as enabling a wakeup pin functionality so the application waits in order to give ample time to connect via SWD and start a debugging session.

For further information regarding this chip and all of its features, you may refer to the documentation in the SDK package, available for download at the product page.

My best regards,
Daniel