Xiao-nrf54l15 An error occurred: Memory transfer fault @ 0x00ffc31c-0x00ffc31f

[grobasoz]

@grobasoz

I think it “could” be that the OE for the UM3301 is supposed to be referenced from VCCA to enable the isolation of the SWDIO signal.

On further analysis I don’t think that’s it

[grobasoz]

It could also be related to bandwidth? The UM3301DA has a high enough bandwidth (~20MHz) but may it may not be suitable for the high speed SWDIO transition requirements. This could be a “load vs isolation” issue?

[Toastee0]

I was thinking that this might be a speed issue, I wonder if it’s just trying to read slightly faster than the device is ready for, getting enough errors and faulting. I believe there’s a way to specify a slower rate on the command line.

[msfujino]

The SWCLK frequency is approximately 1.3MHz.
When running a script on a bricked XIAO, the first attempt always fails. From the second attempt onward, the full erase succeeds no matter how many times it is executed. However, once the power is turned OFF, it bricks again. This cycle repeats. It reproduces very reliably.

[msfujino]

After running the script to perform a full erase and then turning off the power, it bricks again. However, if you upload something like blinky after the full erase, it won’t brick even after turning off the power.

My XIAO suddenly bricks while in use, and since I don’t understand the root cause of the bricking, I don’t know if this method provides a complete fix or if it’s just a temporary solution.

[msfujino]

@msfujino

Regarding my XIAO_nRF54L15, it’s highly likely there’s a hardware issue.
I’m observing signal levels by placing a digital scope probe on the SWDIO and SWCLK pads on the back. The SWDIO pin on the XIAO that cannot upload remains constantly LOW with no changes. The SWDIO pin on the XIAO that can upload is normally HIGH and changes between HIGH and LOW according to the data.

I was observing the signal level by placing the expansion board pins on the pads of the back side, but since the pin tips are rounded, they couldn’t break through the oxide layer on the pads and were causing poor contact.
After soldering them, I was able to observe the level properly.
I don’t think this issue is related to brick.

[Toastee0]

Are you using the nrf54L15 that keeps bricking in an expansion base? I’m curious if this might be related.

[msfujino]

I also use it mounted on an expansion board. Since SWDIO and SWCLK are constantly stimulated, that might be the cause.

[lboue]

I have the problem without any extensions connected.

[Toastee0]

My nRF54L15 has only ever been put into an ap-protect locked up state by my own bad code. Thanks for helping eliminate the carrier board possibility as a cause.

[daCoder]

I had a similar issue as reported by toastee0 with openocd.

    TargetName         Type       Endian TapName            State
--  ------------------ ---------- ------ ------------------ ------------
 0* nrf54l.cpu         cortex_m   little nrf54l.cpu         unknown
 1  nrf54l.aux         mem_ap     little nrf54l.cpu         running

I was able to recover the board with a j-link edu. Claude the AI recommended this set of commands and it recovered the board.

# Launch J-Link Commander
JLinkExe -device nRF54L15_xxAA -if SWD -speed 4000

# In the J-Link prompt:
connect
halt
erase
loadfile firmware.hex
reset
go
exit

I have been avoiding that board so I can’t say if it is fixed for good.