Device: nRF54L15 DK (PCA10156, S/N 1057762414)
Chip: NRF54L15_xxAA_ENGA (engineering sample A)
NCS: v3.4.0 · nRF Connect: v5.3.2 · J-Link: V9.24a (on-board OB)
Problem summary:
The pre-built nrf54l15dk_hello_world.hex from nRF Connect Quick Start was working fine, then stopped. Now it produces no serial output and Serial output timed out or did not receive expected value. A custom blinky sample shows identical behavior.
What I've done / ruled out:
- Full chip recover (
nrfutil device recover, equivalent tonrfjprog --recover) — re-flashed hello_world afterwards. Did NOT fix. - UICR verified factory default —
0xFFFC00all0xFFFFFFFF. No APPROTECT lock. - No Secure Domain / IronSide / boot-mode issues — nrfutil confirms:
Device family nRF54l does not have different boot modes,IronSide SE boot report is not defined for this device. - FLPR core not running (pc=0x2, RRAM empty). No interference from co-processor.
- The hello_world hex IS correctly written to flash — verified by comparing vector table at 0x0 with the hex file byte-by-byte: SP=
0x200011E0, Reset=0x00000D25, all match.
Evidence — CPU jumping to empty flash:
I sampled cpuapp PC 10× after flashing hello_world. The PC values are:
The nrf54l15dk_hello_world.hex covers addresses 0x0 – 0x6372 (25,458 bytes).
All sampled PCs are far beyond the hello_world code range:
| Sampled PC | Offset from 0x6372 | Flash content at that address |
|---|---|---|
0x112E0 |
+0xAF6E (44KB past end) | 0xFF (empty) |
0x24F26-0x24F42 |
+0x1EBB4 (123KB past end) | 0xFF (empty) |
0x2F860-0x2F868 |
+0x294EE (165KB past end) | 0xFF (empty) |
J-Link mem8 reads confirm flash at these addresses is all 0xFF. No HardFault (CFSR=0, HFSR=0). The CPU is executing garbage 0xFFFF… opcodes in empty flash — it never reaches printk() / main().
Key observation: This hex was working on the same board earlier (serial output appeared, Quick Start passed). It stopped working during a debugging session that involved J-Link flash/erase operations (but no UICR writes, no APPROTECT changes, no OTP burns — verified).
Question: Has anyone seen an nRF54L15 ENG-A sample where the Zephyr startup code jumps to a wrong address in empty flash, even after a full recover and re-flash of the correct hex? Could this be a known anomaly of the ENG-A stepping, or a flash integrity / SRAM initialization issue specific to early silicon?
Full log of evidence collected (register dumps, PC traces, hex verification) available on request.
