fix: size CURRENT.UF2 to the real installed app, not the max region

[jamesarich]

Summary

While hardware-testing #19 (nrfx/tinyusb bump) on a real RAK4631, restoring the app via the bootloader's own CURRENT.UF2 (a live dump of the app region, generated by ghostfat.c's read_block()) reproducibly hung the device — even though the bytes being written back were byte-identical to what was already there. A control test confirmed this is pre-existing, not caused by #19: the unmodified, currently-shipped bootloader hangs the exact same way.

Digging into it turned up real history:

• CURRENT.UF2 currently reports/generates content sized to TRUE_USER_FLASH_SIZE — the max possible app+SoftDevice region — regardless of how big the actually-installed app is. On the test device (RAK4631, Meshtastic 2.7.26), that's ~390KB more than the real firmware image (3728 vs 2966 UF2 blocks), padding out with whatever's physically sitting in flash past the real app+SD boundary.
• adafruit/Adafruit_nRF52_Bootloader#38 (2018) fixed a related CURRENT.UF2 problem by sizing it off bootloader_settings.bank_0_size (the real recorded size of the currently-installed app) instead of a fixed constant. That fix has no trace left in the current file — it was dropped somewhere along the way, likely during #128's SoftDevice-decoupling rewrite in 2020 (whose own checklist claims CURRENT.UF2 was tested working at the time).
• adafruit/Adafruit_nRF52_Bootloader#201 (2020) documents copying CURRENT.UF2 back onto the drive as a working community-known recovery trick for devices stuck in DFU mode — so this round-trip is supposed to be reliable, not "expected to be flaky."

Fix

Two commits, both required together:

1. ghostfat.c: restores the same idea as the 2018 fix — current_flash_size(), reading bootloader_settings.bank_0_size with the same zero/erased-flash fallback to the max region — grafted onto the current SoftDevice-decoupled code, which computes the max bound differently (TRUE_USER_FLASH_SIZE, not the 2018 code's constant).
2. msc_uf2.c: found while testing commit 1 — bank_0_size was still being recorded as 0 for any app flashed via plain UF2 drag-and-drop (as opposed to DFU-serial, which populates it correctly), because tud_msc_write10_complete_cb()'s app-completion branch never set update_status.app_size before calling bootloader_dfu_update_process(). Commit 1 does nothing for the common case without this.

Test plan

• tools/build_all.py — all 14 boards build clean
• Hardware retest of the exact CURRENT.UF2 dump-and-restore sequence that hung before, on the same RAK4631 — confirmed fixed. After both commits: CURRENT.UF2 reports exactly 1518592 bytes, an exact match with the official release UF2 (previously 1908736 bytes of padding). Dumped it and copied it straight back — device rebooted in ~2 seconds and came back fully functional, versus the previous indefinite hang / 36-second-then-still-broken behavior (details in PR comments).
• Only one board (RAK4631) hardware-tested. The bank_0_size fix in particular is board-independent (it's in shared usb/ code, not src/boards/), but broader testing before merge is still reasonable for boot-critical code like this.

Summary by CodeRabbit

• Bug Fixes
  • UF2 application updates now accurately reflect the application’s actual size.
  • Generated update files use the appropriate storage range, reducing unnecessary file size and improving compatibility with update tools.
  • Added safe fallback behavior when application size information is unavailable or invalid.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3d15d947-30db-42ef-95f6-2947d58e98e4

📥 Commits

Reviewing files that changed from the base of the PR and between f41dab2 and edd1e4c.

📒 Files selected for processing (2)

• src/usb/msc_uf2.c
• src/usb/uf2/ghostfat.c

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The update process records the written application size. The virtual FAT filesystem uses this value to calculate CURRENT.UF2 sectors, directory size, FAT chaining, and generated UF2 block counts.

Changes

UF2 application sizing

Layer / File(s)	Summary
Record written application size src/usb/msc_uf2.c	Application completion stores _wr_state.numWritten * 256 in update_status.app_size.
Size CURRENT.UF2 dynamically src/usb/uf2/ghostfat.c	The installed application size is rounded to UF2 payload boundaries. Invalid values use TRUE_USER_FLASH_SIZE. FAT chaining, directory metadata, UF2 generation bounds, and block counts use the calculated size.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Merge Risk: ⚪ Minimal · up to edd1e

The change sizes CURRENT.UF2 to the installed application and records that size for UF2 installs; no actionable merge-blocking risk remains, so the PR is merge-ready after normal checks.

Poem

A rabbit checks each UF2 byte,
Records the size just right.
The FAT chain follows every bound,
While smaller files are neatly found.
“Hop!” says the hare, “the blocks align!”

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: sizing CURRENT.UF2 to the installed application instead of the maximum region.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[jamesarich]

Hardware test: confirmed fixed, on the same RAK4631 that reproduced the hang

Found a second bug needed to make this fix actually take effect for the common case (app flashed via plain UF2 drag-and-drop, not DFU-serial): msc_uf2.c's tud_msc_write10_complete_cb() never set update_status.app_size before calling bootloader_dfu_update_process() for a completed app write — it stayed 0 from the initial memset, so bootloader_settings.bank_0_size was always recorded as 0 for any UF2-flashed app, regardless of this PR's ghostfat.c change. Added the missing update_status.app_size = _wr_state.numWritten * 256; assignment (256 = the UF2 format's fixed payload-per-block size) alongside the ghostfat.c fix.

Verified on hardware, step by step:

1. Self-updated the bootloader to this branch's build via the UF2 self-update mechanism (no serial DFU needed for this step).
2. Reflashed the app (official firmware-rak4631-2.7.26.54e0d8d.uf2) under the fixed bootloader.
3. CURRENT.UF2 now reports 1518592 bytes — an exact match with the official release UF2's size (previously 1908736 bytes, ~390KB of padding past the real app).
4. Dumped CURRENT.UF2 and copied it straight back (the exact sequence that hung before, both on this branch's earlier pre-msc_uf2.c-fix state and on the unmodified currently-shipped bootloader in the control test).
5. Device rebooted in ~2 seconds and came back fully functional (screen normal, same node identity) — matching the healthy pattern from a normal firmware flash, not the 36s-or-indefinite-hang pattern from before.

Both commits in this PR are needed together — ghostfat.c alone doesn't change anything until bank_0_size is actually populated correctly.