@@ -158,14 +158,15 @@ itself; a human has to edit it too.
158158 upgrade support with no board here yet (issues #4 , #5 ) — bringing up a
159159 new board needs real hardware to get ` UF2_BOARD_ID ` /VID-PID/pin defs
160160 right; don't fabricate a ` board.h ` without one.
161- - ** ` CURRENT.UF2 ` (the UF2-drive file ` ghostfat.c ` generates live from the
162- already-flashed app region) does not round-trip cleanly.** Copying it off
163- as a backup works fine, but copying it straight back to "restore" the app
164- it came from can leave the device booting into a hung app (frozen
165- display, no LED activity) even though the bytes are identical to what
166- was there before — something about bootloader-settings/app-valid state
167- isn't fully reconciled by that path. Confirmed on real RAK4631 hardware
168- during the nrfx/tinyusb bump testing (PR #19 ). A real release UF2 or a
169- normal OTA-DFU flash both round-trip fine; only the raw dump-and-rewrite
170- doesn't. Untriaged — if you hit this, a fresh release UF2 is the
171- workaround, not a bootloader-settings-format bug hunt mid-task.
161+ - ** ` CURRENT.UF2 ` dump-and-restore used to hang the device — fixed in #20 ,
162+ don't reintroduce it.** Root cause: ` CURRENT.UF2 ` was sized off the max
163+ possible app region (` TRUE_USER_FLASH_SIZE ` ) instead of the real
164+ installed app, AND ` msc_uf2.c ` 's UF2-app-flash completion path never
165+ recorded the real app size into ` bootloader_settings.bank_0_size ` (stayed
166+ 0 from a ` memset ` , only the DFU-serial protocol populated it). Together
167+ that meant restoring a ` CURRENT.UF2 ` dump byte-for-byte could still hang
168+ the device on boot. Both fixed together in #20 (` ghostfat.c ` 's
169+ ` current_flash_size() ` + ` msc_uf2.c ` 's ` update_status.app_size ` ) —
170+ verified on real RAK4631 hardware, the same dump-and-restore sequence
171+ that hung now completes in ~ 2 seconds. If you change either of those two
172+ files, check this still holds.
0 commit comments