Problem
The current design uses microSD over SDMMC. This works but has real downsides for a flight system: card holders are mechanical points of failure, consumer microSD cards have unpredictable stall times during garbage collection, and we have manual SD card handling before launch.
Current State
Each controller has one microSD card connected via SDMMC1 in 4-bit mode at 16 MHz. LittleFS sits on top as the file system. The producer-consumer ring buffer and conditional drain logic in SdStore handle the unpredictable stall behaviour. Worst-case stalls of around 300 ms drive the 600 ms watchdog timeout. The full architecture is documented in the Software Design CDR chapter.
Proposed Approach
Replace the microSD plus SDMMC peripheral with a soldered NOR or NAND flash chip over QSPI or OSPI. LittleFS stays. The block-device backend in SdStore is the only abstraction layer that changes. Capacity drops from gigabytes to tens of megabytes, which is still plenty for our log volumes (BTC under 40 MB, EXP3 around 20 MB).
Alternatives
....
Impact
What components would be affected?
Next Step
If this proposal gains support, the next step is to write an ADR following docs/standards/documentation/adr-template.md and open a PR.
Problem
The current design uses microSD over SDMMC. This works but has real downsides for a flight system: card holders are mechanical points of failure, consumer microSD cards have unpredictable stall times during garbage collection, and we have manual SD card handling before launch.
Current State
Each controller has one microSD card connected via SDMMC1 in 4-bit mode at 16 MHz. LittleFS sits on top as the file system. The producer-consumer ring buffer and conditional drain logic in SdStore handle the unpredictable stall behaviour. Worst-case stalls of around 300 ms drive the 600 ms watchdog timeout. The full architecture is documented in the Software Design CDR chapter.
Proposed Approach
Replace the microSD plus SDMMC peripheral with a soldered NOR or NAND flash chip over QSPI or OSPI. LittleFS stays. The block-device backend in SdStore is the only abstraction layer that changes. Capacity drops from gigabytes to tens of megabytes, which is still plenty for our log volumes (BTC under 40 MB, EXP3 around 20 MB).
Alternatives
....
Impact
What components would be affected?
Next Step
If this proposal gains support, the next step is to write an ADR following docs/standards/documentation/adr-template.md and open a PR.