Memory access error when flashing nRF54L15

RE: Memory access error when flashing nRF54L15

Amanda Hsieh — Tue, 01 Jul 2025 17:00:14 GMT

Hi Wout,

Happy to know you found the issue.

You can have a board-specific conf file for MCUboot (e.g., sysbuild/mcuboot/boards/custom_plank.conf), but you must also provide sysbuild/mcuboot/prj.conf for it to be picked up.

-Amanda H.

RE: Memory access error when flashing nRF54L15

WoutWG — Tue, 01 Jul 2025 15:27:23 GMT

Hi Amanda,

I seem to have found the issue. While trying to isolate the issue by starting from a known good example and slowly adding the devicetree settings and configs of our custom board, I noticed that there seems to be a whole folder of board conf files in the boot/zephyr/boards files. For the nRF54L15DK this conf file disables CONFIG_FPROTECT. When I copied the content of this conf file into my mcuboot.conf file and then do a build with my custom board as build target, I don't get this issue anymore. The moment I comment out CONFIG_FPROTECT=n, the issue comes back.

Now my question is, if I make a custom board, is there an easy way to create a conf file that will be used automatically for mcuboot (something like custom_plank_mcuboot.conf perhaps)? I am using the West T2 topology from the ncs-example-application, so my custom board is defined in that boards directory.

Or will I have to solve this through the application level mcuboot.conf file like I did now?

Best,

Wout

RE: Memory access error when flashing nRF54L15

Amanda Hsieh — Thu, 22 May 2025 12:54:27 GMT

Hi,

[quote user="WoutWG"]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;[/quote]

This line is part of the Zephyr kernel's mutex implementation, which should not be accessed before the kernel is fully initialized and before main() is reached.

[quote user="WoutWG"]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?[/quote]

The bus fault before main() is likely due to a null or invalid pointer dereference in the Zephyr kernel mutex code, possibly caused by uninitialized kernel objects. If mcuboot or the application image is misconfigured, or if there is a mismatch between the board and the image, faults can occur before main(). Ensuring the correct board target and a clean flash is important.

-Amanda H.

RE: Memory access error when flashing nRF54L15

WoutWG — Thu, 22 May 2025 08:29:11 GMT

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

RE: Memory access error when flashing nRF54L15

Amanda Hsieh — Wed, 07 May 2025 14:50:38 GMT

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

See Optional programming parameters.

RE: Memory access error when flashing nRF54L15

WoutWG — Wed, 07 May 2025 12:50:49 GMT

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?

RE: Memory access error when flashing nRF54L15

Amanda Hsieh — Tue, 29 Apr 2025 13:20:51 GMT

Hi,

[quote user=""]Would that be the reason for getting this error, and can I fix it by using the non-secure environment? [/quote]

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.