Firmware architecture

Bare metal with a cooperative scheduler, not FreeRTOS

FreeRTOS is the reflex answer and it is the wrong one here.

Your workload is a handful of periodic tasks at 1–100 Hz with no blocking I/O that cannot be made non-blocking with DMA. That is exactly what a cooperative scheduler handles well. Reliability over feature count — RTOS bugs are hard to reproduce, and you cannot attach a debugger at 25 km.

Structure

main()
 ├── hw_init()            clocks, GPIO, peripherals, IWDG
 ├── boot_forensics()     read RCC_CSR -> backup SRAM, increment boot counter
 ├── config_gnss()        UBX: airborne <1g dynamic model  <-- CRITICAL
 ├── self_test()          probe every sensor, set status_flags
 └── while(1) scheduler_run()

scheduler: 1 kHz SysTick tick, table of {period_ms, last_run, fn}

Task table

Total worst case ≈ 35 ms per second of an 84 MHz budget. Enormous headroom, deliberately.

Rules that keep it deterministic

1. No task blocks. Ever. Every driver is a state machine driven by the scheduler. HAL_Delay() does not appear anywhere after hw_init().
2. All bus traffic is DMA. SPI, SDIO and both radio UARTs.
3. Two I²C buses. Bus 1: environmental sensors. Bus 2: power monitors. A single hung device cannot take down the whole sensor set. Implement an I²C bus recovery routine (clock out 9 bits, generate STOP) and call it on timeout.
4. Watchdog kicked from one place only — task_health, and only if every other task ran within its deadline. A watchdog kicked unconditionally from the main loop protects nothing.

The memory experiment state machine (M7)

Sliced across scheduler calls so it never blocks. One full cycle ≈ 60 s.

IDLE -> WRITE_PATTERN -> SETTLE -> TRISTATE -> STEP_DOWN -> HOLD
     -> RESTORE -> READ_BACK -> CLASSIFY -> REPORT -> IDLE

In parallel, every cycle: CRC32 the STM32's internal SRAM and Flash using the hardware CRC unit and compare against the value stored at boot. This is the internal-versus-external comparison, and it costs almost nothing.

Three things that make the result defensible:

• The pattern is regenerated from a seed, not stored. A stored copy could itself be corrupted, and you would never know which side flipped.
• Rail voltage is logged with every result. A bit error with a coincident rail dip is a power event, not a memory event, and you can prove it.
• Reset reason is logged. An error after an unlogged reset is meaningless.

Fault handling

Flight phase detection

Drives SPS30 power, log rate and telemetry rate.

LANDED mode matters more than it sounds. The recovery phase can last hours and it is when you most need the radio alive.

Build and tooling

Development order (start today on the dev board)

1. Blink, clocks, SysTick, UART console, IWDG.
2. Scheduler skeleton with dummy tasks and deadline monitoring.
3. One driver at a time against a breakout board: MS5611 → TMP117 → SHT45 → ICM-42688 → AS7331 → INA226.
4. GNSS: UBX parser plus the airborne dynamic-model configuration. Test this one hard — it is the single highest-consequence line of firmware in the project.
5. SD logging with SDIO+DMA and a raw circular log (no FAT).
6. Telemetry packet builder, CRC, and both radio drivers.
7. Memory test state machine (needs the real PCB's DAC/LDO — stub V_MEM with a fixed rail on the dev board until then).
8. Flight phase detection, fault handlers, backup SRAM forensics.

Steps 1–6 are all doable on a €12 dev board with breakout sensors, in parallel with PCB layout and fabrication. That is the whole point of buying it today.