Repository navigation
build(esp32): NightDriverStrip partitions CSV rejected by esp32-core-3.3.9 gen_esp32part.py (nvs 0x2000 < 0x3000) #960
Description
Context
With #955 fixed (project-relative partitions CSV resolution, PR #958), NightDriverStrip demo's config/partitions_custom_noota.csv is now correctly found and passed to gen_esp32part.py. But the generator that ships with the resolved framework (esp32-core-3.3.9) rejects the CSV content:
WARN gen_esp32part.py failed: Partition nvs invalid: 'nvs' partition of type 1 and subtype 2 of this size (0x2000) must be flagged as 'readonly' (the size of read/write NVS has to be at least 0x3000)
NightDriverStrip's CSV declares nvs, data, nvs, 0x00b000, 0x002000 (8 KB). A newer esp-idf rule requires read/write NVS to be ≥ 0x3000 (12 KB). The workload's CSV predates that rule.
Consequences: partitions.bin is not produced, so the ESP32 fast-path fingerprint still can't persist for this project (blocks the whole-build short-circuit that would take #951's 2.1 s no-op rebuild down to ~0.5 s).
Open question — framework version parity
NightDriverStrip pins platformio/espressif32 @ ^6.12.0. fbuild resolved esp32-core-3.3.9. Worth confirming whether PlatformIO's espressif32@6.12.0 resolves the same arduino-esp32 core / gen_esp32part.py version — if PlatformIO builds this CSV fine, fbuild may be resolving a newer core than the pin implies (an A/B parity divergence), which is the real fbuild-side bug. If PlatformIO's 6.12.0 also rejects it, this is purely a stale workload CSV and belongs upstream in NightDriverStrip.
Acceptance criteria
- Determine which esp32 core
espressif32@6.12.0resolves under PlatformIO vs fbuild. - If divergent: fix fbuild's platform→core resolution to match the pin.
- If matched: document that the workload CSV needs the nvs partition widened to 0x3000 (upstream / harness-local patch), out of fbuild scope.
Decisions
- Priority: P3 — does not affect perf(build): no-change rebuild recompiles the entire sketch + core variant (~103s; should be seconds) #951's merged no-op-rebuild win (that comes from the per-TU staleness path, not the fast-path fingerprint). Only blocks the incremental whole-build skip for projects with custom partitions.
Activity
zackees commentedon Jul 6, 2026
Investigation complete — out of fbuild-core scope (stale workload CSV)
Per the acceptance criteria, determined what each side resolves:
esp32_platform.rsPLATFORM_URL = pioarduino/platform-espressif32/releases/download/**stable**,PLATFORM_VERSION = "stable". There is no code that parses or honors the project'splatform = espressif32 @ ^6.12.0pin — the entire ESP32 path is intentionally built on pioarduino, which ships arduino-esp32 3.3.9 and its strictergen_esp32part.py(read/writenvsmust be ≥ 0x3000).platformio/espressif32 @ ^6.12.0resolves the legacy arduino-esp32 2.0.x core, whose oldergen_esp32part.pyaccepts NVS 0x2000.So the resolution does diverge (fbuild 3.x vs the pin's 2.x) — but the divergence is a deliberate fbuild design choice (pioarduino is the maintained fork;
platformio/espressif326.x is frozen on arduino-esp32 2.x), not an accidental resolution bug. The decision-tree's "fix fbuild's resolution to match the pin" branch would mean reverting fbuild's entire pioarduino/3.x ESP32 stack for one CSV — not desirable, and NightDriverStrip otherwise compiles + links + produces firmware.bin cleanly on 3.x (verified in #987/#988 e2e runs).Conclusion: NightDriverStrip's
config/partitions_custom_noota.csv(nvs … 0x002000) is stale for arduino-esp32 3.x. The fix is widening the nvs partition to ≥ 0x3000 (or flagging itreadonly) upstream in NightDriverStrip or as a harness-local patch — out of fbuild-core scope. fbuild correctly passes the CSV and the framework correctly rejects it.The broader question of whether fbuild should honor explicit
espressif32@Xversion pins (rather than always pioarduino-stable) for A/B parity is a separate, larger design topic than this partition-CSV issue and is not blocking — filing separately if it proves worth pursuing. Closing #960 as out-of-scope per the acceptance criteria's "matched → document" branch.