boards: seeed: xiao_nrf54lm20a: commit RRAM write-buffer after flash load - #115162
boards: seeed: xiao_nrf54lm20a: commit RRAM write-buffer after flash load#115162lboue wants to merge 1 commit into
Conversation
…load The nrf54lm20a-load OpenOCD proc flashes with load_image but never commits the RRAM controller's internal write-buffer. The final (partial) 128-bit write line is left uncommitted, so the last ~16 bytes of the flashed image are never programmed. Whatever data lands at the tail of the image is silently corrupted. In one observed case (a Zephyr HCI controller build), the tail held net_buf pool structs at the end of the initialized-data region, so hci_rx_pool's alloc/__bufs pointers were left NULL, and the controller took a MemManage fault (data access near address 0x0) when allocating an event buffer to answer the first received HCI command -- presenting as a controller that is simply "silent", with no obvious cause. It is layout-sensitive, so unrelated config changes (e.g. enabling CONFIG_LOG) can appear to "fix" or "break" it by shifting what lands in the dropped tail. Trigger RRAMC.TASKS_COMMITWRITEBUF (0x5004e008) after load_image to flush the write-buffer so the final line is programmed. Register offsets per the nRF54LM20A MDK (RRAMC base 0x5004e000, TASKS_COMMITWRITEBUF @ 0x008). Same fix as Seeed's own out-of-tree board copy (Seeed-Studio/platform-seeedboards#59); ported here since this in-tree board file still has the bug. Verified locally: west flash programs the tail to exactly match the built hex, and firmware built against this checkout (ESPHome's zephyr platform, targeting this board) runs correctly across resets, where it previously did not. Signed-off-by: Ludovic BOUÉ <938089+lboue@users.noreply.github.com>
|
Hello @lboue, and thank you very much for your first Pull Request (PR) to the Zephyr Project! All PRs must pass our Continuous Integration (CI) pipeline before merging. When the pipeline run for your PR completes, you are expected to investigate the results, fix any errors, and update your PR for a fresh round of review. Since this is your first contribution, a project community member must manually approve your CI run (this helps us avoid abuse of our CI system). A bot should assign some reviewers who can start the run for you soon. As a heads-up, you will probably have to update your PR to fix CI issues and address review feedback in order to get it ready for merge. Some key rules for updating your PR are:
Also, see:
If you are stuck or need help, you can join us on Discord and ask questions; many community members try to help new contributors there 😊. Try to pick a Discord channel that is associated with the technical details of your request. If you're not sure, use the #general channel. |
|
2 participants
The
nrf54lm20a-loadOpenOCD proc (boards/seeed/xiao_nrf54lm20a/support/openocd.cfg) flashes withload_imagebut never commits the RRAM controller's internal write-buffer. The final (partial) 128-bit write line is left uncommitted, so the last ~16 bytes of the flashed image are never programmed.Whatever data lands at the tail of the image is silently corrupted. In one observed case (a Zephyr HCI controller build), the tail held
net_bufpool structs at the end of the initialized-data region, sohci_rx_pool'salloc/__bufspointers were left NULL. The controller then took a MemManage fault (data access near address0x0) when allocating an event buffer to answer the first received HCI command -- presenting as a controller that is simply "silent," with no obvious cause. It's layout-sensitive, so unrelated config changes (e.g. enablingCONFIG_LOG) can appear to "fix" or "break" it by shifting what lands in the dropped tail.Fix
Trigger
RRAMC.TASKS_COMMITWRITEBUF(0x5004e008) afterload_imageto flush the write-buffer so the final line is programmed. Register offsets per the nRF54LM20A MDK (RRAMCbase0x5004e000,TASKS_COMMITWRITEBUF@0x008).This is the same fix as Seeed's own out-of-tree copy of this board (Seeed-Studio/platform-seeedboards#59) -- porting it here since this in-tree board file still has the bug.
Testing
Verified locally against this board (real hardware, XIAO nRF54LM20A):
load_imagewithout the commit left the tail unchanged.west flashprograms the tail to exactly match the built hex, byte for byte.Note: I separately have an open, unresolved issue with BLE advertising never being detected by a scanner on this same board, with and without this fix applied (Seeed-Studio/platform-seeedboards#65) -- unrelated as far as I can tell (this fix only affects the fixed tail bytes of whatever image is flashed, and the BLE symptom is present independent of what's at the tail), but flagging it here in case it turns out to matter.