Repository navigation
Conversation
The bundled MDK was 8.73.2, which knows the nRF54LM20A only as
NRF54LM20A_ENGA_XXAA (engineering rev A) and whose nrf.h dispatched to
nrf54lm20a_enga{,_interim,_name_change}.h -- files that were never in the
tree. Production silicon, including the Seeed XIAO nRF54LM20A, identifies
as plain NRF54LM20A_XXAA, so restoring the deleted ENGA files would have
been the wrong target.
8.75.1 is the MDK pinned by NCS 3.3.0, the same SDK the s145 v10.0.1
SoftDevice is built from. It is the first version carrying production
nrf54lm20a.* headers. 8.76.0 was rejected: it additionally moves
NRF_MEMORY_PERIPHERALSAPB{S,NS}_BASE for nRF54L15, which is risk without
benefit here.
Cost to the existing L05/L10/L15 targets is small -- the per-SoC headers
change by a copyright year and one added NRF_GPIOHSPADCTRL define;
system_nrf54l.c picks up the ENGA-to-production renames; nrf54l_erratas.h
grows for the new SoCs.
The nrfx dispatch already carried NRF54LM20A branches under the ENGA name,
so this renames rather than adds: the guards in nrfx_soc_defines.h,
nrfx_irqs.h and nrfx_mdk_fixups.h, and the two nrfx_irqs_nrf54lm20a_enga_*
headers. All nine LM20A blocks were verified byte-identical to the
production blocks in upstream nrfx at the same revision, so the rename is
content-preserving.
No LM20A .svd is added; the tree carries none for any SoC.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 WalkthroughPriority: ➖ Normal Change: Feature Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation |
|---|---|---|
| Description Check |  |
Check skipped - CodeRabbit’s high-level summary is enabled. |
| Title check | |
The title clearly and concisely summarizes the two main changes: updating the MDK to 8.75.1 and adding nRF54LM20A device headers. |
| Docstring Coverage | |
No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 4… |
| Linked Issues check | |
Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | |
Check skipped because no linked issues were found for this pull request. |
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
A rabbit checks each header,
New device names join the list,
DMA fields settle into place,
Radio shortcuts mark the way,
Memory maps span the garden,
The patch hops into review.
Comment @coderabbitai help to get the list of available commands.
|
Afaik the 10.1 softdevice asks for a different memory layout, that would be a breaking change on L15 for no real gain on that architecture. Does it make sense to split that between the trees or shoulld wee break once and early? |
|
#8 itself is only the MDK bump; it doesn't touch the SoftDevice. The 10.0.1 move would have been the next piece, so I tried it on an L15-DK first (details in andyshinn/nRF54_Arduino#1). On the L15 the layout change is only the SoftDevice base, 0x158C00 → 0x15A800 (10.0.1 is about 7 KB smaller). The application, InternalFS and the bootloader settings page stay where they are, and after an SWD reflash without a chip erase the node kept its config and BLE bonds. The break is getting there. A board on 9.0.0 can't do it by DFU: the bootloader can't replace the SoftDevice, and its interrupt forwarding is built for the old base. Every L15 out there would need a one-time SWD reflash of SoftDevice + bootloader. And a 10.0.1 package sent over DFU to a v0.3.0 bootloader erases the application before it's rejected, which leaves the board in the bootloader. So I'd split it: keep L05/L10/L15 on 9.0.0 and use 10.0.1 only for the LM20A, which needs it. The platform already picks the SoftDevice per board through |
First of the pieces @andyshinn suggested in andyshinn#1 for bringing his nRF54LM20A work over: his MDK bump, 2aa44f6 from
ashinn/nrf54lm20a, cherry-picked onto master unchanged and with his authorship. It applies cleanly, and only touchescores/nRF5/nordic/nrfx/.What it changes
From the commit message: MDK 8.73.2 → 8.75.1, the MDK pinned by NCS 3.3.0 and the first with the production nRF54LM20A headers (
NRF54LM20A_XXAA, where 8.73.2 only knewNRF54LM20A_ENGA_XXAA). The LM20A branches in the nrfx dispatch are renamed from the ENGA names, content unchanged. nrfx itself stays at 4.2.0.The move to the s145 10.0.1 SoftDevice is not in here; it will be a separate PR.
Effect on the nRF54L15
I built Meshtastic's
nrf54l15dkenv twice from the same firmware tree (clean builds), once against master and once against master + this commit, and compared the two ELFs:SystemInitchanges (+16 bytes):RRAMC->POWER.LOWPOWERCONFIGis now read-modify-write (clearMODE, then setPowerOff) instead of a plain write ofPowerOff. Every other function is the same, instruction for instruction. The remaining byte differences are pointers to code placed afterSystemInit, shifted by 16 bytes (vector table and data tables)..dataand.bssare unchanged.SAADC_EASYDMA_CURRENT_AMOUNT_REGISTER_INCLUDED0 → 1, the newTWIMxx_CORE_FREQUENCYandUARTExx_DMAEND_PRESENT) change no code in that build.Testing
nRF54L15-DK, bootloader v0.3.0, s145 9.0.0. Flashed the application over SWD, then read the state over SWD without halting the CPU:
LOWPOWERCONFIGreads 3 (PowerOff)Not covered: the L05 and L10 (no hardware here), and core code that the Meshtastic build doesn't link. Nothing on master builds for the LM20A yet, so this PR on its own doesn't exercise the new headers.
Summary by CodeRabbit
New Features
Bug Fixes