fix(nrf52): map PIO nRF52DK variant to Adafruit pca10056 - #322
Conversation
Every `Build nRF52840 DK` workflow run on main fails at:
fatal error: variant.h: No such file or directory
cores/nRF5/Uart.h:27:10
27 | #include "variant.h"
Root cause: fbuild ships only Adafruit's `framework-arduinoadafruitnrf52`
(URL hardcoded in `nrf52_core.rs`). Adafruit's framework has
`variants/pca10056/` (PCA10056 = Nordic's product code for the
nRF52840-DK board) — verified via GitHub API. PIO's nordicnrf52 board
JSON for `nrf52840_dk` says `variant = "nRF52DK"`, which is the name
in *sandeepmistry's* `arduino-nRF5` framework — the one PIO actually
selects for this board upstream. fbuild's `get_variant_dir` joined
the literal name, pointed at a nonexistent `variants/nRF52DK/`, and
`cores/nRF5/Uart.h`'s `#include "variant.h"` failed to resolve.
PlatformIO papers over the framework difference invisibly because it
selects the right framework per-board. fbuild can't (yet), so the
surgical fix is a small per-framework alias map: when the literal
variant dir is missing, try the known-equivalent Adafruit name.
Same shape as #319's SAMD `build.core = "adafruit"` -> `cores/arduino/`
fallback. Both are instances of "PIO upstream names a thing one way,
the installed framework names it differently, fbuild's lookup needs
to paper over the difference."
Refactored the lookup into a small pure `resolve_nrf52_variant_dir`
helper with a private `nrf52_variant_alias` table (currently just
`nRF52DK -> pca10056`). Four new tests cover: alias resolves,
literal-when-present wins, no-match returns literal, literal-takes-
precedence-over-alias.
Local: 11/11 nrf52 tests pass.
Fixes #321.
|
Warning Review limit reached
More reviews will be available in 28 minutes and 45 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Bundles four user-facing fixes merged since 2.2.9: - #319, #320: SAMD51 cores/arduino fallback + variant include injection (Build SAMD51J was 100% red) - #321, #322: nRF52 nRF52DK -> pca10056 variant alias for Adafruit framework (Build nRF52840 DK was 100% red) - #298 (already shipped 2.2.9, board JSON drift cleanup): #318 catches up the tinyuf2 partition renames + adds cmsis_dsp_lib validator whitelist (Validate Boards was failing on 39 boards, now 14) - #317: daemon.rs Command::new annotations (Lint subprocess spawns was red — blocked every PR) Downstream FastLED bumps fbuild==2.2.9 to fbuild==2.2.10 to pick up these fixes.
Summary
Build nRF52840 DKfails on every main run with:Reproducible: every recent run of the workflow.
Root cause
fbuild ships one nRF52 framework — Adafruit's
framework-arduinoadafruitnrf52(URL hardcoded incrates/fbuild-packages/src/library/nrf52_core.rs).The
nrf52840_dkboard JSON declaresbuild.variant = "nRF52DK"(matching PIO upstream — the board-validator agrees). But Adafruit's framework doesn't have avariants/nRF52DK/directory. It hasvariants/pca10056/— PCA10056 is Nordic's product code for the nRF52840-DK, so it's the right hardware. Verified via GitHub API:GET /repos/adafruit/Adafruit_nRF52_Arduino/contents/variants?ref=1.6.1listspca10056, nonRF52DK.variants/nRF52DK/is the name used in the other nRF52 Arduino framework — sandeepmistry'sarduino-nRF5(the one PIO actually selects for this board upstream). fbuild doesn't ship that one.PlatformIO papers over the difference invisibly by picking the right framework per board. fbuild can't (yet), so the immediate failure is the variant compile's include path pointing at a nonexistent
variants/nRF52DK/.Fix
Same shape as #319's SAMD
build.core = "adafruit"→cores/arduino/fallback. Add a tiny per-framework alias table so PIO-matching board JSONs still resolve to the right Adafruit-named directory:Wired into
Nrf52Cores::get_variant_dir. Both pre-existing Adafruit boards (adafruit_feather_nrf52840_sense,nice_nano_nrf52840, etc.) continue to resolve literally — alias only kicks in when the literal dir is missing.Why not just install sandeepmistry's framework?
Considered (and recommended in the issue as the "ideal" fix), but it's a substantial new package + resolver + per-board framework selection. The alias table is a one-line fix per affected board and unblocks CI immediately. We can revisit the framework-set decision when more sandeepmistry-only boards land.
Test plan
cargo test --lib -p fbuild-packages nrf52— 11/11 passing (4 new tests: alias resolves, literal-when-present wins, no-match returns literal, literal-takes-precedence-over-alias)cargo test --lib -p fbuild-packages— 410+/0 passingBuild nRF52840 DKworkflow turns green on next main pushBuild Adafruit Feather NRF52840 Sensecontinues to pass (its board JSON uses Adafruit-nativefeather_nrf52840_senseso the alias path is never entered)Fixes #321.