Memory access error when flashing nRF54L15

[WoutWG]

Hi,

We are working with a custom board that uses the nRF54L15 and I seem to be getting a lot of errors (but not always) related to memory access error when flashing the MCU either from our J-Link Base or from an nRF54L15-DK debug out connector:

[Probe] Device error: Memory access error at 0x00009c70. Probably a memory protection issue. Probe access is Secure (Generic)

Sometimes it works when I try again, but the solution that always works seems to be to erase the MCU and then try to flash again. But it needs to happen in 2 separate operations. When I do the erase and flash board action with the nRF Connect extension in vscode, I also get the error the first time, but it works the second time. I have never had this issue before working with the nRF52 series.

I'm currently on toolchain "b620d30767" that's part of NCS v2.9.0. The build configuration is targetting our own custom board files which are based on the nRF54L15-DK but I am not using the _ns suffix. Would that be the reason for getting this error, and can I fix it by using the non-secure environment? Or do you have any other pointer as to what could be going wrong?

Best,

Wout

[Amanda Hsieh]

Hi, 

Would that be the reason for getting this error, and can I fix it by using the non-secure environment?

No. That is configured for the build type. 

The error might be a memory protection issue. Try to recover the board before flashing. 

If you still have problems,  try to call "nrfutil --version" and "nrfutil device --version", and provide the return log. 

Regards,
Amanda H.

[WoutWG]

Hi Amanda,

Recovering the board works, but it seems to only work once.

Here is the output of nrfutil device --version

nrfutil-device 2.7.16 (688c8df 2025-02-17)
commit-hash: 688c8dfc89c904714c4916c5ae3e14b8ff45fa83
commit-date: 2025-02-17
host: x86_64-pc-windows-msvc
build-timestamp: 2025-02-17T14:53:45.482985000Z
classification: nrf-external

Detected SEGGER J-Link version: JLink_V8.26

The device command version you are currently using was tested with a different J-Link version (JLink_V8.10f) than the one you have installed (JLink_V8.26). The tested version is not required, and your J-Link version will most likely work fine. If you get issues related to J-Link with your devices, use the tested version.

Could this have something to do with the more recent J-Link version? 

[Amanda Hsieh]

It needs to be recovered to unlock the device with readback protection. 

See Optional programming parameters. 

[WoutWG]

Hi Amanda, 

I have some more input on this (as it keeps happening). As I mentioned, recovering works, but only once. Same for erasing the board. 

I noticed some issues with debugging as well: the debugger immediately breaks for a fatal error before hitting main. This is also not consistent. If I restart the debugger a couple of times, I can get to main() and run the program correctly. Similarly, I tried flashing the board multiple times, and sometimes it works without erasing or recovering. 

So it seems that there is a bug somewhere in the code resulting in a hard fault resetting the processor. If I can time the flashing or debugging right, it works well, but if not flashing or debugging will fail due to the hard fault. Since the hard fault is happening before hitting main in my application, I wonder if you have any pointers what this could be?

We are using mcuboot and an application targetting nrf54l15_cpuapp (not NS variant)

00> [00:00:17.255,295] <err> os: ***** BUS FAULT *****
00> [00:00:17.255,301] <err> os: Precise data bus error
00> [00:00:17.255,305] <err> os: BFAR Address: 0x55
00> [00:00:17.255,317] <err> os: r0/a1: 0xe867d0cf r1/a2: 0x0000002c r2/a3: 0x00000089
00> [00:00:17.255,325] <err> os: r3/a4: 0x00000000 r12/ip: 0x0000d0cf r14/lr: 0x00000375
00> [00:00:17.255,329] <err> os: xpsr: 0x00000000
00> [00:00:17.255,333] <err> os: Faulting instruction address (r15/pc): 0x00030374
00> [00:00:17.255,355] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
00> [00:00:17.255,370] <err> os: Current thread: 0x20003c50 (unknown)
00> [00:00:18.210,898] <err> os: Halting system

Using addr2line I don't get anything for r14, but the r15 register points to zephyr/kernel/mutex.c:259 (ncs v2.9.1), which is this line: mutex->owner = new_owner;

Let me know if you need any additional information.

Best,

Wout