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.