Repository navigation
nrf7002dk flash headroom: earlier measurements retracted, needs a verified build to assess #61
Description
The measurements originally in this issue are retracted. Do not rely on them.
They were produced by a run where make ... | tail reported tail's exit status rather than the build's, so failed builds looked like successes, and by a toolchain we could not confirm matched CI. Every byte count previously here, the 944 KB region size, the 100.00% figures and the 44 and 12 bytes free, came from that run. All of it is withdrawn.
Recording the question anyway, because flash pressure on nordic_nrf7002dk constrains what we can add to shared ports/zephyr-cp code.
What is actually verified
Checked against adafruit main:
- Two of the 37 zephyr-cp board directories disable modules.
nordic/nrf7002dkdisables six (aesio,adafruit_bus_device,zlib,jpegio,tilepalettemapper,gifio), more than any other board.nordic/nrf54h20dkdisables three. Every other zephyr-cp board disables nothing. - CI builds the board.
ports (zephyr-cp) / board (nordic_nrf7002dk)is one of 27 zephyr-cp board jobs, so a change that overflows it turns CI red. - It carries Adafruit's VID
0x239Awith PID0x8168, and Scott Shawcroft is the most frequent author of its board files. - It passed CI on supervisor/web_workflow: check the listener socket calls for failure adafruit/circuitpython#11207, so as of that commit it still links.
The six disabled modules are the strongest signal that the board is tight, since nothing else in the tree needs that treatment. That is an inference from configuration, not a measurement.
What is not known
How much flash headroom the board actually has, and therefore whether small additions to shared zephyr-cp files are safe. Answering that needs a build with a toolchain confirmed to match CI, with the exit status checked properly.
One early version of the scan timeout patch did fail to link on this board with a FLASH region overflow. That build came from the same unverified setup, so treat it as a hint that the margin is small rather than as evidence of any specific number.
The question
If the margin really is small, it is worth asking directly rather than guessing: should fixes touching shared zephyr-cp code be conditional, should another module be disabled on that board, or is it due for a different partition layout.
Relevant to #57, #58, #59 and PR #60, all of which touch shared zephyr-cp files.
Activity
[-]nrf7002dk on adafruit main is at 100% flash, which caps what we can add to shared zephyr-cp code[/-][+]nrf7002dk flash headroom: measurements retracted, needs a Zephyr SDK build to assess[/+]mikeysklar commentedon Aug 17, 2026
Retracting the numbers in this issue. They came from a broken build script and a toolchain that does not match CI, so they do not support the conclusion.
What was wrong
The wrapper used to build
nordic_nrf7002dkwas:$?after a pipeline istail's status, so it was always 0, andtail -25truncated the log so the linker error often fell outside what was then grepped. Every "builds OK" for that board in this issue is unverified.Re-run with
set -o pipefail, the exit code captured directly, and a check thatzephyr.elfactually exists:fb2568d8a0unmodifiedregion FLASH overflowed by 840 bytes30ae4d5c77unmodified (after the bleio merge)So the board was already failing here before any of our changes. The claim that our timeout patch overflowed it by 28 bytes, and the 44 and 12 byte headroom figures, are all withdrawn.
Why it probably is not an upstream break
This build uses Homebrew
arm-none-eabi-gcc14.3 throughZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb, not the Zephyr SDK that Adafruit CI uses. Code size differs between them, so an overflow here does not mean an overflow there. Upstream CI for the bleio merge was still running when this was checked, so its result is unknown either way.What is still true
The board does carry
DISABLED_MODULES=["aesio", "adafruit_bus_device", "zlib", "jpegio", "tilepalettemapper", "gifio"]and is the only zephyr-cp board that disables anything, so it is genuinely the tightest board in the port. That much is visible in the tree and does not depend on my build.But flash headroom cannot be measured meaningfully from this setup. Anyone wanting a real number needs the Zephyr SDK toolchain, or should read it off a CI artifact.
The SiWx917 build results elsewhere in these issues used a different wrapper that checks the exit code directly and confirms
zephyr.rpswas produced, so those are unaffected.[-]nrf7002dk flash headroom: measurements retracted, needs a Zephyr SDK build to assess[/-][+]nrf7002dk flash headroom: earlier measurements retracted, needs a verified build to assess[/+]