Skip to content

fix(nrf52): map PIO nRF52DK variant to Adafruit pca10056 - #322

Merged
zackees merged 1 commit into
mainfrom
fix/nrf52-variant-alias-321
May 30, 2026
Merged

fix(nrf52): map PIO nRF52DK variant to Adafruit pca10056#322
zackees merged 1 commit into
mainfrom
fix/nrf52-variant-alias-321

Conversation

@zackees

@zackees zackees commented May 30, 2026

Copy link
Copy Markdown
Member

Summary

Build nRF52840 DK fails on every main run with:

fatal error: variant.h: No such file or directory
cores/nRF5/Uart.h:27:10
    27 | #include "variant.h"

Reproducible: every recent run of the workflow.

Root cause

fbuild ships one nRF52 framework — Adafruit's framework-arduinoadafruitnrf52 (URL hardcoded in crates/fbuild-packages/src/library/nrf52_core.rs).

The nrf52840_dk board JSON declares build.variant = "nRF52DK" (matching PIO upstream — the board-validator agrees). But Adafruit's framework doesn't have a variants/nRF52DK/ directory. It has variants/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.1 lists pca10056, no nRF52DK.

variants/nRF52DK/ is the name used in the other nRF52 Arduino framework — sandeepmistry's arduino-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:

fn nrf52_variant_alias(variant_name: &str) -> Option<&'static str> {
    match variant_name {
        // nRF52840-DK: PIO/sandeepmistry name -> Adafruit/PCA product-code name.
        "nRF52DK" => Some("pca10056"),
        _ => None,
    }
}

fn resolve_nrf52_variant_dir(variants_dir: &Path, variant_name: &str) -> PathBuf {
    let primary = variants_dir.join(variant_name);
    if primary.is_dir() { return primary; }
    if let Some(aliased) = nrf52_variant_alias(variant_name) {
        let candidate = variants_dir.join(aliased);
        if candidate.is_dir() { return candidate; }
    }
    primary
}

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 passing
  • CI Build nRF52840 DK workflow turns green on next main push
  • Sanity-check Build Adafruit Feather NRF52840 Sense continues to pass (its board JSON uses Adafruit-native feather_nrf52840_sense so the alias path is never entered)

Fixes #321.

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.
@coderabbitai

coderabbitai Bot commented May 30, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@zackees, we couldn't start this review because you've reached your PR review rate limit.

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 68707846-f936-4af8-8581-8888cdd1db1c

📥 Commits

Reviewing files that changed from the base of the PR and between b7560aa and 5078e0b.

📒 Files selected for processing (1)
  • crates/fbuild-packages/src/library/nrf52_core.rs
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/nrf52-variant-alias-321

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@zackees
zackees merged commit 9eaeddc into main May 30, 2026
76 of 83 checks passed
zackees added a commit that referenced this pull request May 30, 2026
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Build nRF52840 DK fails: variant nRF52DK absent in installed Adafruit framework

1 participant