Repository navigation
Conversation
…ice tree No S145 release ships either header; they belong to this port. Keeping them under s145_nrf54l_9.0.0 ties the build to that one SoftDevice directory. src/ precedes the SoftDevice API directory on the include path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Brings every variant onto one SoftDevice version, matching what nRF54LM20A already used. Sourced from nrfconnect/sdk-nrf-bm components/softdevice/nrf54l/s145 (git_revision 75a7b53a). 10.0.1 ships a separate hex per SoC, where 9.0.0 shipped one for the family, so SD_CHIP_FAMILY becomes SD_CHIP and names the SoC. That also fixes a real bug: nrf54l05 and nrf54l10 were both handed the 9.0.0 hex, which is built for nRF54L15 and links at 0x158C00. Flashing it to an L05 or L10 put the SoftDevice outside the part's RRAM. 10.0.1 is 5.4 KB smaller than 9.0.0, so it starts 0x1C00 higher: 0x5A800 / 0xDA800 / 0x15A800. SOFTDEVICE_REGION_START has to follow or is_sd_existed() reads the wrong address, finds no magic number and quietly falls back to serial DFU. The bootloader settings page stays put, so the freed 7 KB goes to the application data region and existing app data survives the upgrade. No API migration: the s145 migration document has no 10.0.1 section, its newest entry is 9.0.0, and the 10.0.1 headers are byte-identical to the ones already vendored for nRF54LM20A. The SoftDevice RAM requirement drops from 0x1780 to 0x1480, so the 0x20004800 split stays valid. The DFU FWID changes from 0x3024 to 0x310D, so --sd-req must be updated when generating packages. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> [cvaldess: cherry-picked onto meshtastic master, which has no nRF54LM20A support yet: the nRF54LM20A branches in CMakeLists.txt and dfu_types.h, its README column and the MCU_STARTUP selection are left out; the L05/L10/L15 changes are as in the original.]
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage |  |
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 40 files. (8 skipped: 8… | Write docstrings for the functions missing them to satisfy the coverage threshold. |
-
Check name Status Explanation 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. Description Check Check skipped - CodeRabbit’s high-level summary is enabled. Title check The title clearly and concisely describes the primary change: moving the nRF54L05, nRF54L10, and nRF54L15 configurations to the s145 10.0.1 SoftDevice.
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 40 files. (8 skipped: 8 unsupported.)
- Fix all pre-merge checks with AI
- 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 the hex files by moonlit light
New SoC paths are sorted just right
GATT types hop into place
SoftDevice numbers find their space
Then quiet paws review the change tonight
Comment @coderabbitai help to get the list of available commands.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First of the three PRs for the move to s145 10.0.1, in the order @caveman99 set in andyshinn/nRF54_Arduino#1: this bootloader first, released so the hex files are on the tag; then the core, meshtastic/nRF54_Arduino#9; then the platform, meshtastic/platform-nordicnrf54#3, moving both pins and the boards together.
It's @andyshinn's c4778bd and 1d14806 from
ashinn/nrf54lm20a, cherry-picked onto master with his authorship:nrf_nvic.handble_l2cap.hshims out of the vendored SoftDevice tree intosrc/. 1d14806 needs it: without it the build loses both headers when the 9.0.0 directory goes away.SD_CHIPinstead ofSD_CHIP_FAMILY),SOFTDEVICE_REGION_STARTat 0x5A800 / 0xDA800 / 0x15A800, and the DFU FWID from 0x3024 to 0x310D. It also fixes the L05 and L10 being handed the L15's 9.0.0 hex. Master has no nRF54LM20A support yet, so its branches inCMakeLists.txtanddfu_types.h, its README column and theMCU_STARTUPselection are left out; the commit message says so.Migration
This bootloader only runs with the 10.0.1 SoftDevice, and the v0.3.0 bootloader can't be updated by DFU (no MBR). Boards on 9.0.0 need a one-time reflash over SWD of the SoftDevice, this bootloader and an application built for 10.0.1 (the XIAO boards through their onboard CMSIS-DAP).
flash-sdandflash-bootloaderonly erase the sectors they write, so they keep them (then the application as usual).flash-allstarts with--eraseall.Until then, don't send a DFU package built for 10.0.1 to a board on v0.3.0: the single-bank code erases bank 0 when the start packet arrives and only checks
--sd-reqafterwards, so the board is left in the bootloader with no application. #3 fixes that for later updates (the package is checked before bank 0 is invalidated) and is meant to go in before this release.Testing
Built for all five boards (
nrf54l05dk,nrf54l10dk,nrf54l15dk,xiao_nrf54l15,xiao_nrf54l15_sense, MinSizeRel as in CI); each one forwards to its own 10.0.1 base.nRF54L15-DK, from bootloader v0.3.0 + s145 9.0.0: flashed this bootloader, the 10.0.1 SoftDevice and a Meshtastic build for 10.0.1 over SWD, without a chip erase. It boots into the application, which keeps its config and BLE bonds: an existing bond reconnected, and a fresh LESC pairing worked. Details in meshtastic/nRF54_Arduino#9.
Not covered: the L05, L10 and XIAO boards on hardware, serial DFU and BLE OTA through this bootloader.
Summary by CodeRabbit
0x3024identifier require a SoftDevice reflash.