blackbox: continue an SD log in a new file when it can't grow by MrScothh · Pull Request #12060 · iNavFlight/inav

MrScothh · 2026-09-28T10:25:48Z

Builds on #12056 and #12057. The first commits are #12056 (the freefile refilled at boot) and #12057 (the SD cache): the refill writes to the FAT while a new log's header goes out, and without #12057's corrected count of free buffer space the header can lose bytes. On the bench 2 of 7 files lost part of their header without it, 0 of 7 with it. Then come this PR's commits, and copies of the later fixes of #12056 and #12057.

With #12056 the freefile is refilled at boot, so every power cycle starts with up to 4 GB for logs. Within one power cycle it still only shrinks: when it runs out, or a log reaches 4 GB (the largest FAT32 file), the blackbox stops for the rest of the flight although the card may have plenty of room. PX4 handles the same FAT32 limit by closing the log and starting a new file (SDLOG_MAX_SIZE); this does the same for INAV's SD blackbox.

The change

It is a build option, USE_BLACKBOX_SDCARD_SPLIT, defined with the other larger optional features in common.h, so it is on for targets with more than 512 KB of flash and off on the 512 KB F7 targets.

afatfs, in the background (afatfs_poll), once the freefile is below 256 MB:

extends it over the free clusters that follow it, 16 MB at a time, the same way as at boot in afatfs: regrow the blackbox freefile at boot, so the card is not full after 4 GB of logs #12056 (chain, flush, link, flush, save the size), so the log keeps growing in the same file;
if nothing free follows it, searches the FAT for the largest free block (reads only, interleaved with the log's writes);
once the freefile has run out and the log that used it has been closed, frees its last cluster and builds a new freefile at the start of that block, which step 1 then extends.

Regular cluster allocations wait while clusters are being claimed, and a claim doesn't start while one of them may be under way, so the two can't take the same cluster. A contiguous file can no longer grow past 4 GB either; with the freefile refilled it now could.

Blackbox: when the log file can't grow any more but afatfs can make room, it closes the log instead of stopping, and the usual start path opens the next LOGxxxxx.TXT as soon as there is room. Every iteration spent on the new file's header is a gap in the log, so while it is sent the blackbox skips the 100 ms wait for a serial port and takes several header steps per iteration, within 50 us, as long as the SD card cache has 2 KB to spare. That margin matters: afatfs_getFreeBufferSpace() counts the cache sectors held for open files as free, and without it the header outran the card and lost its sysinfo lines. The SD card only counts as full (OSD, MAVLink, arming a new log) once no new file can get room either.

Two paths the split takes and today's blackbox doesn't:

A new file waits until the freefile has room for its first supercluster. Created earlier, while the freefile was being refilled, it would get no cluster, be split at once and, with no frame logged, deleted. Deleting a contiguous file with no clusters ran the contiguous erase of the FAT from cluster 0 up to the freefile, and then moved the freefile's start to cluster 0. Today's blackbox never deletes such a file (a full card sends it straight to stopped), but the split does, so truncating a file with no clusters now only saves its directory entry. When no room can come, the file opens as it does today and the full card stops the log.
When a regular cluster allocation (a directory that needs another cluster, for example) finds no free cluster, the card is full beyond the freefile. The refill no longer clears the full flag then, and the blackbox stops as it does without the option.

Testing

TBS Lucid H7 Wing (H743, SDIO), 16 GB card, logging at 2 kHz (about 170 KB/s), with bench-only CLI commands to shrink the freefile (freeing its tail in the FAT, optionally with an occupied cluster right after it), to pause the refill, and to set a fake file size limit.

test	what happened	gap between files
extension while logging	freefile shrunk to 24 MB with free clusters after it: back to 266 MB within 6 s, 16 MB at a time; the log stayed in one file (80,616 frames in 41 s), freefile chain contiguous	none
move	freefile shrunk to 12 MB with an occupied cluster after it: extension blocked, the background search found the largest free block; when the freefile ran out, the log closed at exactly 12 MB and the next file started on the new block, which was then extended to 274 MB; chain contiguous	31 ms
file size limit (fake, 8 MB)	three files of exactly 8 MB	17-18 ms
several moves in one flight (second Lucid H7 Wing, own card, 1 kHz, 63 kB/s)	freefile cut to 24 MB, FAT-only files leaving 21 free blocks of 12.5 MB; 15 minutes of logging, three times: each run moved four times and left five files (24 MB, three of 8 MB, the last), each decoding on its own; the search for the next block took about 3 s, in the background, right after each move	each move under 0.1 s
a really full card (before #12056's latest change was merged in)	FAT-only files leaving only holes of 64 clusters: the log stopped where the freefile ran out, without splitting, and decodes with no iteration missing; a new log on the full card stays empty, as without this PR	none

Repeated after the review fixes on top of the other SD PRs (cache, pause, block writes): every file decoded with its full header and 0% of iterations missing; the in-flight extension kept one file (81,382 frames in 41 s), the move split at exactly 12 MB with a 27 ms gap, the fake limit gave three 8 MB files with 16-20 ms gaps, and after each of three reboots the freefile was back to 4,190,240 KB with a contiguous chain. Before the fixes, and with this PR alone, every file decoded with 0 to 1% of iterations missing, the same as without a split on this card (its 54 ms write stalls, which the cache and pause PRs deal with). The background search ran while logging with no visible effect on the frame rate. With one header step per iteration, as the blackbox does at arming, the gaps were 83 and 68 ms. The PID task's longest run over the three-file test was 145 us, against 134 us with one step per iteration.

In the three 15-minute runs one or two files had gaps, 3.4 to 13.9 s in all, from writes turned down because the cache was full. A bench build timestamped the refill's phases and the turned-down writes: the refill was idle at every gap, far from any search or move, so these are that card's own write stalls of 0.2 to 0.6 s (#12058 marks them as pauses). Afterwards the FAT-only files were removed, and the 57 logs already on the card had the same CRC as before.

USE_TERRAIN with a refill running, on the same board with a terrain file on its card and HITL flying a route over it: with the refill as it was, fifteen 16 MB claims took 0.5 s at the start, before terrain began to read; terrain then got 40 of 40 accesses, loaded its 13 blocks, and the log had no gap. With the block search slowed down on purpose to last the whole flight, terrain got the card only once the search ended, 200 s later; with d655443 (below), 0.2 s after the search began, and it loaded all 13 blocks on time. The log had no gap either way.

Flash: +1,212 B on TBS_LUCID_H7_WING, +1,380 B on MATEKH743, +1,424 B on MATEKF405SE; MATEKF722SE unchanged (option off). SITL builds.

Not tested:

SD cards on SPI (F4, F7): the background search shares the bus with the log's writes and takes longer there.
The real 4 GB limit (only the fake 8 MB one).

If anyone logs long flights to an SD card, especially on an F4 or F7 board with the SD on SPI, I'd like to know whether the log continues in a new file and how long the gap is.

After review

The refill is kept out of line, like afatfs: regrow the blackbox freefile at boot, so the card is not full after 4 GB of logs #12056's mount code, so it stays out of the F7's ITCM.
A failed link or directory save stops the refill until the next mount instead of retrying forever.
The fixes from afatfs: regrow the blackbox freefile at boot, so the card is not full after 4 GB of logs #12056's and afatfs: count only the cache sectors that can take data, and size the cache per MCU family #12057's review.
afatfs: regrow the blackbox freefile at boot, so the card is not full after 4 GB of logs #12056's latest change, merged in (f63952b): at boot the freefile is grown, and given back when it moves, 256 MB at a time, its directory entry saved after each step. The refill while logging already claims 16 MB at a time and saves the size after each claim, so it needed no change.

Built on F4, F7, H7, AT32 and SITL; KAKUTEF7 and KAKUTEF7HDV fit their ITCM. On the TBS Lucid H7 Wing after review: extension in flight (one file), a move to another block (gap 29 ms) and a fake 8 MB file limit (three files, gaps 17 and 18 ms), no iteration missing in any file, FAT chains contiguous.

After merging #12056's change, on the same board: six resets at set points of a boot that moved the freefile (two in the FAT search, one while the old freefile was given back, two while the new one grew, one after the work) each left a freefile whose chain was as long as its size; the extension in flight kept one file (81,450 frames in 41 s) and the move continued in a new file with a 29 ms gap, no iteration missing in either file. Flash +272 B on MATEKF722SE (98.66%), +408 B on MATEKF405SE, +480 B on TBS_LUCID_H7_WING; ITCM unchanged on KAKUTEF7 and KAKUTEF7HDV.

On 2026-10-08, three more commits:

d655443: the blackbox hands the card to terrain only when afatfs is idle, and a refill in progress counted as busy, so terrain waited for the whole refill. Now terrain gets the card while the refill only searches the FAT for its next block; claims, links and releases still make it wait.
537faed merges afatfs: regrow the blackbox freefile at boot, so the card is not full after 4 GB of logs #12056's 99dc078, which writes the boot regrow's FAT a sector at a time.
84e5a12 does the same for the refill in flight: a claim's FAT is written from its last sector back, each sector on the card before the one before it. On the bench a test build reset the board inside a claim after 1, 2, 3 and 4 of its FAT sectors: each time no FAT entry pointed at a free cluster or at the freefile's head, the cut left one chain ending in a terminator, and the next boot rebuilt a 4 GB freefile with a contiguous chain.

Flash against f63952b: +80 B on MATEKF722SE (98.67%), +264 B on MATEKF405SE, +224 and +208 B on KAKUTEF7 and KAKUTEF7HDV, +240 B on an H743, +296 B on an AT32F435; ITCM and RAM unchanged.

Related PRs

blackbox: pause instead of dropping frames while the SD card is busy #12058 and blackbox: hand the device a block of bytes, not one byte per call #12059 also rework blackboxUpdate() and conflict with this one in blackbox.c. Whichever is merged second, I'll rebase it.

On 2026-10-19: ed03967 clears regularFull when a file is deleted, so the room freed when the blackbox deletes an empty log goes to the next log without a new mount (from Qodo's review of #12158).

…boot The freefile is created once, on the largest free block of the card and at most 4 GB (the largest FAT32 file), and reused as it is at every later boot. Its size is a whole number of superclusters plus one cluster, so once the logs have taken the superclusters one cluster is left: the card reads as full and the blackbox stops logging until the card is formatted, although the rest of a card larger than 4 GB and any log deleted from a PC are free. When the freefile is below 2 GB at boot, search the FAT for the largest free block as on the first boot, and if that is larger, free the old freefile's clusters and move the freefile there. Larger freefiles are reused without a search, as before.

…w it Logs take their clusters from the start of the freefile, so it only ever shrank until the next format, and one log could never grow past what was left of it at boot. On a card larger than 4 GB the clusters that follow the freefile are normally free, so at boot extend it over them, up to the largest file size, leaving AFATFS_FREEFILE_LEAVE_CLUSTERS for regular files as a new freefile does. Only a freefile that is still below 2 GB afterwards is moved to the largest free block. The new clusters are chained and flushed before the freefile's last cluster points at them, and the new size is saved after that, so a power cut leaves at worst unreferenced clusters, never a chain that runs into free ones.

After the skip the search went on reading the FAT sector of the freefile's first cluster while the cluster number had moved past it, so the entries it examined belonged to other clusters. It could only matter when those sectors were already cached, and the search at boot now runs with the freefile in place.

afatfs_FATFillWithPattern() counted a final FAT sector it only writes part of among the sectors to pre-erase. That sector has to be read first, and on an SD card on SPI the read ends the multiple-block write started with ACMD23 before it reaches that block; the SD specification leaves an unwritten pre-erased block undefined, erased or old. Its other entries, which can belong to the next file, could then be read back erased. A new freefile ends that way (whole superclusters plus one cluster), and so does every extension of it.

afatfs_getFreeBufferSpace() counted every unlocked sector that was empty or in sync, but afatfs_allocateCacheSector() never evicts one with a retain count: a contiguous file keeps its directory entry retained for as long as it is open, and the blackbox log and the free file are both contiguous. With a log open, two of the 8 sectors were reported as space the blackbox could write into, and could not be. Measured on a TBS Lucid H7 while the SD card held a write for 54 ms: afatfs_fwrite() refused bytes while this function still reported 1024 bytes free.

An SD card can hold a write for tens of milliseconds (the standard allows 250). The blackbox keeps writing into the other cache sectors meanwhile, and once none is left it drops what it writes. With 8 sectors, and 3 of them never free while a log is open, the cache held about 30 ms of a 1 kHz log. Measured on a TBS Lucid H7 whose card holds a write for 54 ms every 768 KB once it runs out of prepared blocks, 120 s logs: sectors 1 kHz log (85 kB/s) 2 kHz log (170 kB/s) rows lost rows lost 8 379 2178 12 8 1282 16 0 703 24 0 0 32 0 0 (also over a 20 minute log) Now 32 sectors on H7 and 24 on F7, where RAM is plenty. On F4 with the card on SPI the cache moves to CCM with 24 sectors: RAM is short there, CCM mostly unused, and the CPU writes the card, so no DMA needs to reach it. Elsewhere (F4 with SDIO, AT32) it stays at 8. A target can set AFATFS_NUM_CACHE_SECTORS itself. Targets without an SD card do not link the cache. Walking the larger cache costs afatfs_poll() about 8 ns per sector on the H7, in the scheduler's idle loop.

… card has room With the freefile refilled at boot, every power cycle starts with up to 4 GB for logs, but within one power cycle the freefile only shrinks: when it runs out, or a log reaches the largest FAT32 file, the blackbox stops for the rest of the flight although the card may have room. Behind USE_BLACKBOX_SDCARD_SPLIT, on by default on targets with more than 512 KB of flash, afatfs refills the freefile in the background once it is below 256 MB: it extends it over the free clusters that follow it, 16 MB at a time, and when nothing free follows it searches the FAT for the largest free block, and moves the freefile there once it has run out and the log that used it has been closed. Regular cluster allocations wait while clusters are being claimed, and a contiguous file can no longer grow past the largest file size. The blackbox closes a log that can't grow when afatfs can make room, instead of stopping, and the usual start path opens the next file once there is room, without waiting for a serial port before the header. The card only counts as full once no new file can get room either.

…in a time budget

…a full card stops as before A log created while the freefile was being refilled could not grow, so the blackbox split it at once and, with no frame logged, deleted it. Deleting a contiguous file with no clusters ran the contiguous erase from cluster 0 up to the freefile. Truncating a file with no clusters now only saves its directory entry, and a split log's new file waits until the freefile has room for its first supercluster, as long as the refill can still bring some: when it can't, the file opens as without the option and the full card stops the log. When a regular cluster allocation finds no free cluster, the card is full for more than the freefile: the refill no longer clears that, and the blackbox stops as it did without the option.

qodo-code-review · 2026-09-28T10:25:54Z

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

qodo-free-for-open-source-projects · 2026-09-28T10:27:55Z

PR Summary by Qodo

Continue SD blackbox logging in a new file when a log cannot grow

✨ Enhancement 🐞 Bug fix ⚙️ Configuration changes 🕐 40+ Minutes

AI Description

• Refill SD free space at boot and during logging so available card space remains usable.
• Continue logging in a new file when the current file exhausts its space or reaches FAT32's limit.
• Fix empty-file truncation and cache accounting encountered during log splitting.

Diagram

graph TD
  Poll["afatfs poll"] --> Low{"Freefile low?"} -->|Yes| Extend["Extend freefile"]
  Extend -->|Blocked| Search["Find free block"] --> Move["Move freefile"] --> Next["Open next log"]
  Poll --> Logger["Blackbox logger"] --> Limit{"Log cannot grow?"} -->|Room elsewhere| Next

High-Level Assessment

The following are alternative approaches to this PR:

1. Preallocate multiple freefiles at boot

➕ Could avoid a full FAT search during a flight when the active freefile runs out.
➖ Reserves more card space up front and complicates allocation of space for ordinary files.
➖ Still requires log rollover at FAT32's per-file size limit.

Recommendation: The background refill and existing numbered-log lifecycle are the better fit: they use available space without reserving multiple large files at boot. Review should focus on allocation interlocks, power-loss ordering, and the untested full-card and SPI-card paths.

Files changed (6) +570 / -16

Enhancement (5) +568 / -16

blackbox.cSplit a running SD log and accelerate its replacement header +43/-1

Split a running SD log and accelerate its replacement header
• Transitions a log that cannot grow into shutdown when another file can receive data. Sends the replacement file's header in time-bounded extra steps, then returns to normal logging.
src/main/blackbox/blackbox.c

blackbox_io.cDistinguish a full log from a full SD card +29/-1

Distinguish a full log from a full SD card

• Waits for freefile space before creating a replacement log and reports the card as full only when logging cannot continue in another file. Adds helpers for rollover eligibility and spare cache capacity.

src/main/blackbox/blackbox_io.c

blackbox_io.hDeclare SD log rollover and cache-capacity helpers +4/-0

Declare SD log rollover and cache-capacity helpers
• Exposes feature-gated checks used by the blackbox state machine.
src/main/blackbox/blackbox_io.h

asyncfatfs.cRegrow, relocate, and safely allocate the FAT freefile +488/-14

Regrow, relocate, and safely allocate the FAT freefile

• Extends or relocates a shrunken freefile at boot and adds a background refill state machine for logging. Interlocks regular allocations with cluster claims, enforces FAT32 file-size bounds, adjusts cache sizing and accounting, and fixes FAT search, write, and empty-file truncation cases.

src/main/io/asyncfatfs/asyncfatfs.c

asyncfatfs.hExpose freefile continuation and room checks +4/-0

Expose freefile continuation and room checks
• Declares feature-gated filesystem queries used to decide whether a new SD log can start.
src/main/io/asyncfatfs/asyncfatfs.h

Other (1) +2 / -0

common.hEnable SD log splitting on larger-flash targets +2/-0

Enable SD log splitting on larger-flash targets
• Adds the build option alongside other features enabled when MCU flash exceeds 512 KB.
src/main/target/common.h

qodo-free-for-open-source-projects · 2026-09-28T10:30:56Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~Repeated log moves permanently consume card space~~ ✓ Resolved

Description

afatfs_ftruncate() captures the contiguous endpoint from afatfs.freeFile.firstCluster and then
clears that same handle, so truncating the freefile clears an empty FAT range and underflows the
size saved by the prepend path. Both boot-time and background relocation invoke this path before
installing the replacement freefile, leaving old clusters allocated and, if interrupted, potentially
leaving an invalid directory entry.

Code

src/main/io/asyncfatfs/asyncfatfs.c[R3797-3801]

+                        if (afatfs.freeFile.logicalSize > 0) {
+                            // Give the old freefile's clusters back first; the move continues in afatfs_freeFileReleased()
+                            afatfs.initPhase = AFATFS_INITIALIZATION_FREEFILE_RELEASE;
+                            afatfs_ftruncate(&afatfs.freeFile, afatfs_freeFileReleased);
+                            goto doMore;

Evidence
Both relocation paths call afatfs_ftruncate() on afatfs.freeFile. Truncation captures the
original first cluster as the contiguous endpoint, then zeroes file->firstCluster; the contiguous
continuation consequently clears a range whose start and end are equal, reads zero as the old
freefile start, subtracts the nonzero original cluster, and saves the resulting underflowed size
before the replacement is installed.
src/main/io/asyncfatfs/asyncfatfs.c[2557-2594]
src/main/io/asyncfatfs/asyncfatfs.c[2670-2701]
src/main/io/asyncfatfs/asyncfatfs.c[3797-3801]
src/main/io/asyncfatfs/asyncfatfs.c[3958-3965]
src/main/io/asyncfatfs/asyncfatfs.c[2663-2689]
src/main/io/asyncfatfs/asyncfatfs.c[2564-2579]
src/main/io/asyncfatfs/asyncfatfs.c[3960-3965]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Relocating the freefile truncates the freefile itself through a contiguous-file path that assumes a different target file. This fails to release the old FAT chain and can persist an underflowed freefile size before the replacement is installed.
## Fix Focus Areas
- src/main/io/asyncfatfs/asyncfatfs.c[2557-2594]
- src/main/io/asyncfatfs/asyncfatfs.c[2663-2689]
- src/main/io/asyncfatfs/asyncfatfs.c[3797-3801]
- src/main/io/asyncfatfs/asyncfatfs.c[3958-3965]
## Recommended Fix
Add a dedicated freefile-release operation, or explicitly handle `file == &afatfs.freeFile` in truncation, that clears the old FAT chain and directory entry without deriving the contiguous endpoint from or prepending clusters to the same handle. Use it in both relocation paths, invoke the relocation callback only after release succeeds, and verify that interruption at each persisted step leaves a valid freefile entry.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~Interrupted refills lose card space~~ ✓ Resolved

Description

AFATFS_REFILL_CLAIM_UPDATE_FAT marks clusters allocated before the refill links them to the
existing freefile or saves the new freefile's directory entry. A power loss between those steps, or
a FAT-write failure after earlier sectors were updated, leaves allocated clusters outside the
recorded freefile; the next boot's free-space search treats them as occupied.

Code

src/main/io/asyncfatfs/asyncfatfs.c[R4030-4033]

+        case AFATFS_REFILL_CLAIM_UPDATE_FAT:
+            // Chain the claimed clusters before linking them: a power cut never leaves a chain into free ones
+            status = afatfs_FATFillWithPattern(AFATFS_FAT_PATTERN_TERMINATED_CHAIN, &refill->claimCursor, refill->claimEnd);
+

Evidence
The FAT writer advances through sectors and can fail after updating earlier ones. Refill stops
without reversing those updates, while successful claims are linked or recorded only in later
states; startup extension stops at occupied clusters.
src/main/io/asyncfatfs/asyncfatfs.c[1471-1481]
src/main/io/asyncfatfs/asyncfatfs.c[1490-1529]
src/main/io/asyncfatfs/asyncfatfs.c[4030-4075]
src/main/io/asyncfatfs/asyncfatfs.c[3692-3715]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Refill claims can leave allocated clusters unreachable when FAT construction fails partway through or power is lost before the freefile metadata is updated.
## Fix Focus Areas
- src/main/io/asyncfatfs/asyncfatfs.c[4030-4043]
- src/main/io/asyncfatfs/asyncfatfs.c[4045-4075]
- src/main/io/asyncfatfs/asyncfatfs.c[3692-3727]
## Recommended Fix
Track and undo partially written claims on operation failure. Add an interruption-safe recovery strategy for claims persisted before their link or directory entry, so startup can reclaim them rather than treating them as permanently occupied.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. ~~A failed link leaves refilling stuck~~ ✓ Resolved

Description

AFATFS_REFILL_CLAIM_LINK advances only when afatfs_FATSetNextCluster() succeeds and does not
handle its failure result. If the FAT operation fails, subsequent polls remain in the same refill
phase, so the refill never completes or reports a terminal failure.

Code

src/main/io/asyncfatfs/asyncfatfs.c[R4047-4051]

+                status = afatfs_FATSetNextCluster(refill->claimStart - 1, refill->claimStart);
+
+                if (status == AFATFS_OPERATION_SUCCESS) {
+                    refill->phase = AFATFS_REFILL_CLAIM_SAVE_DIR_ENTRY;
+                }

Evidence
afatfs_FATSetNextCluster() explicitly returns a failure status, but the new refill phase checks
only success. The boot-time extension path handles failure from the same operation, showing that it
cannot be treated as an in-progress result.
src/main/io/asyncfatfs/asyncfatfs.c[1225-1254]
src/main/io/asyncfatfs/asyncfatfs.c[4045-4053]
src/main/io/asyncfatfs/asyncfatfs.c[3740-3755]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The background refill link phase ignores a terminal FAT-write failure and retries in the same phase indefinitely.
## Fix Focus Areas
- src/main/io/asyncfatfs/asyncfatfs.c[4045-4053]
- src/main/io/asyncfatfs/asyncfatfs.c[4054-4078]
- src/main/io/asyncfatfs/asyncfatfs.c[3739-3755]
## Recommended Fix
Handle `AFATFS_OPERATION_FAILURE` explicitly in the refill link phase, transition to a terminal or recoverable error state, and account for clusters already claimed. Apply equivalent failure handling to the following directory-entry save phase.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Tip of the day

💡 Did you know, you can import rules and skills only from the repositories your team follows

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

…f retrying forever

github-actions · 2026-09-28T14:33:24Z

RAM / Flash usage vs. base commit 13ebed9 — commit ed03967

Target	Flash Δ	RAM Δ
MATEKF405 ⚠️	+2504 B (+0.35%)	CCM: +12308 B (+37.80%) RAM: -3840 B (-3.68%)
MATEKF722 ⚠️	+704 B (+0.15%)	ITCM_RAM: ±0 B (±0.00%) RAM: +8488 B (+9.78%) TCM: ±0 B (±0.00%)
MATEKF765 ⚠️	+3816 B (+0.50%)	DTCM_RAM: -4 B (-0.01%) SRAM1: +8512 B (+6.79%)
MATEKH743 ⚠️	+3380 B (+0.42%)	D2_RAM: ±0 B (±0.00%) DTCM_RAM: ±0 B (±0.00%) ITCM_RAM: +24 B (+0.16%) RAM: +12712 B (+8.93%)

See RAM/flash optimization guide for techniques to reduce usage.

github-actions · 2026-09-28T14:33:30Z

Test firmware build ready — commit ed03967

Download firmware for PR #12060

251 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

…rectory entry each step A power cut while the freefile was regrown or moved at boot left whatever chain was in flight as a lost FAT chain: up to 4 GB of new chain, and up to 2 GB of the old freefile when moving it. Three cuts on a TBS Lucid H7 Wing left three lost chains of 650 MB on average. The new chain now grows in 256 MB blocks, each one chained, linked, saved and flushed before the next. A moved freefile gives its old clusters back the same way from its end: the smaller size is saved, then the chain is cut there, then the tail is freed. A cut strands at most one block either way.

… end and freeing from the front

…next block

…eature/blackbox-sd-split

MrScothh · 2026-10-08T09:56:05Z

Tests of the items listed as untested above, and three commits on top.

Several moves in one flight, on a second TBS Lucid H7 Wing (SDIO, its own card), with a bench build that fills the card's FAT. The freefile was cut to 24 MB, and FAT-only files left 21 free blocks of 400 clusters (12.5 MB) on the card. Then I logged at 1 kHz (63 kB/s) for 15 minutes, three times.

Each run moved four times and left five files: 24 MB, three of 8 MB and the last one, each decoding on its own.
A move took under 0.1 s, and the search for the next block about 3 s, in the background, right after it.
In each run one or two files had gaps, 3.4 to 13.9 s in all, from writes turned down because the cache was full. The third run's bench build timestamped the refill's phases and the turned-down writes: the refill was idle at every gap, far from any search or move, so these are this card's own write stalls of 0.2 to 0.6 s. With blackbox: pause instead of dropping frames while the SD card is busy #12058 they would be marked pauses instead.
Afterwards the FAT-only files were removed, and the 57 logs that were already on the card had the same CRC as before.

USE_TERRAIN with a refill running, on the same board with a terrain file on its card and HITL flying a route over it:

With the refill as it was, fifteen 16 MB claims took 0.5 s at the start, before terrain began to read; terrain then got 40 of 40 accesses, loaded its 13 blocks, and the log had no gap.
The blackbox hands the card to terrain only when afatfs is idle, and a refill in progress counted as busy, so terrain waited for the whole refill. d655443 lets terrain in while the refill only searches the FAT for its next block; claims, links and releases still make it wait.
Same HITL flight, with the block search slowed down on purpose to last the whole flight: before d655443, terrain got the card only once the search ended, 200 s later; with it, 0.2 s after the search began, and it loaded all 13 blocks on time (40 of 40 accesses). The log had no gap either way.

A really full card, on 2026-10-07 with this PR before #12056 was merged in: FAT-only files left only holes of 64 clusters. The log stopped where the freefile ran out, without splitting, and decodes with no iteration missing; a new log on the full card then stays empty, as without this PR.

The other two commits:

537faed merges afatfs: regrow the blackbox freefile at boot, so the card is not full after 4 GB of logs #12056's 99dc078, which writes the boot regrow's FAT a sector at a time.
84e5a12 does the same for the refill in flight: a claim's FAT is written from its last sector back, each sector on the card before the one before it. On the bench Lucid, a bench build reset the board inside a claim after 1, 2, 3 and 4 of its FAT sectors. Each time the whole FAT had no entry pointing at a free cluster or at the freefile's head, the cut left one chain ending in a terminator, and the next boot rebuilt a 4 GB freefile with a contiguous chain.

Flash against f63952b: +80 B on MATEKF722SE (98.67%), +264 B on MATEKF405SE, +224 and +208 B on KAKUTEF7 and KAKUTEF7HDV, +240 B on the H743, +296 B on an AT32F435; ITCM and RAM unchanged.

The real 4 GB limit is still untested.

sensei-hacker · 2026-10-16T14:20:52Z

I was thinking that as you noted, 4 GiB is about 14 hours of flight, so maybe it would be simpler to make it a circular buffer -- when you hit the end, go back to the beginning. So it never runs out of space. You always have the last ~14 hours of flight on the CD card.

Actually implementing that, it wasn't as simple as I was thinking, but it is about half as much code as as what's here. Which of the two do you think is best?

#12150

MrScothh · 2026-10-16T20:42:36Z

@sensei-hacker thanks for checking it out. The circular buffer isn't a bad idea at all, but I personally like to use all the space on the SD card, and that's just my own preference.

About the three afatfs bugs you found, do they happen on the base branch too? If so, I think they deserve a PR of their own.

…new log regularFull stayed set after the regular allocation that failed, so the room freed when blackbox deleted an empty log was never offered to the next one until the card was mounted again.

MrScothh · 2026-10-20T09:06:32Z

The deltas include the PRs this one builds on, against an older base: the RAM is #12057's larger afatfs cache (24 sectors in CCM on F4 with the card on SPI, 24 on F7 and 32 on H7 in RAM, where there were 8), and the flash is mostly #12056 and #12057. MATEKF722 has 512 KB of flash and doesn't build this PR's code (USE_BLACKBOX_SDCARD_SPLIT is only on larger targets): its +704 B is #12056 and #12057.

MrScothh added 9 commits September 28, 2026 00:22

blackbox: send a split log's header several steps per iteration, with…

c8ce3ef

…in a time budget

qodo-free-for-open-source-projects Bot reviewed Sep 28, 2026

View reviewed changes

Comment thread src/main/io/asyncfatfs/asyncfatfs.c

Comment thread src/main/io/asyncfatfs/asyncfatfs.c

Comment thread src/main/io/asyncfatfs/asyncfatfs.c

MrScothh added 5 commits September 28, 2026 14:35

afatfs: keep the mount code out of the F7's ITCM

9f908bf

afatfs: keep the mount code out of the F7's ITCM

f46fc85

afatfs: keep the freefile refill out of the F7's ITCM

eeae2de

afatfs: a refill that fails to link or save its entry stops instead o…

dd22fd7

…f retrying forever

afatfs: an F4 card on SPI keeps its cache in CCM whatever its size

9da70af

MrScothh force-pushed the feature/blackbox-sd-split branch from 9da70af to b0cf99d Compare September 28, 2026 18:10

MrScothh added 2 commits September 28, 2026 21:19

docs: what the onboard SD card does with its free space

4d7f2b3

afatfs: shorter comment, and docs for the log split and the freefile

1747ab4

MrScothh force-pushed the feature/blackbox-sd-split branch from b0cf99d to 1747ab4 Compare September 28, 2026 19:20

sensei-hacker added this to the 10.1 milestone Oct 5, 2026

sensei-hacker added the Testing Required label Oct 5, 2026

MrScothh added 2 commits October 6, 2026 23:33

Merge maintenance-10.x into fix/afatfs-freefile-regrow

c1eb20e

Merge maintenance-10.x into feature/blackbox-sd-split

b5651ca

MrScothh mentioned this pull request Oct 7, 2026

F7: enable the D-cache, DMA buffers in a non-cacheable SRAM2 region #12119

Open

MrScothh added 6 commits October 7, 2026 18:43

Merge fix/afatfs-freefile-regrow into feature/blackbox-sd-split

f63952b

afatfs: write the freefile's FAT a sector at a time, growing from the…

99dc078

… end and freeing from the front

afatfs: let terrain read its files while the refill searches for the …

d655443

…next block

Merge remote-tracking branch 'fork/fix/afatfs-freefile-regrow' into f…

537faed

…eature/blackbox-sd-split

afatfs: chain an in-flight claim from its last FAT sector back

84e5a12

MrScothh mentioned this pull request Oct 16, 2026

afatfs: report the whole SD card's free space over MSP #12156

Open

MrScothh mentioned this pull request Oct 18, 2026

afatfs: the free space count and the freefile refill take turns (#12156 with #12060) #12158

Open

afatfs: a deleted file clears the latch that kept a full card from a …

ed03967

…new log regularFull stayed set after the regular allocation that failed, so the room freed when blackbox deleted an empty log was never offered to the next one until the card was mounted again.

Navigation Menu

Repository navigation

blackbox: continue an SD log in a new file when it can't grow - #12060

blackbox: continue an SD log in a new file when it can't grow#12060
MrScothh wants to merge 25 commits into
iNavFlight:maintenance-10.xfrom
MrScothh:feature/blackbox-sd-split

MrScothh commented Sep 28, 2026 •

edited

Loading

Uh oh!

qodo-code-review Bot commented Sep 28, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 28, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 28, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented Sep 28, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 28, 2026 •

edited

Loading

Uh oh!

MrScothh commented Oct 8, 2026

Uh oh!

sensei-hacker commented Oct 16, 2026

Uh oh!

MrScothh commented Oct 16, 2026

Uh oh!

MrScothh commented Oct 20, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

MrScothh commented Sep 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The change

Testing

After review

Related PRs

Uh oh!

qodo-code-review Bot commented Sep 28, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 28, 2026

PR Summary by Qodo

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented Sep 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Sep 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MrScothh commented Oct 8, 2026

Uh oh!

sensei-hacker commented Oct 16, 2026

Uh oh!

MrScothh commented Oct 16, 2026

Uh oh!

MrScothh commented Oct 20, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

MrScothh commented Sep 28, 2026 •

edited

Loading

qodo-free-for-open-source-projects Bot commented Sep 28, 2026 •

edited

Loading

github-actions Bot commented Sep 28, 2026 •

edited

Loading

github-actions Bot commented Sep 28, 2026 •

edited

Loading