STM32F407 (NUCLEO-F407 / STM32F4-DISCO)
The STM32F407VGT6 (Cortex-M4F, 1 MB flash, 192 KB SRAM — 128 KB main + 64 KB CCM not yet declared) is the hardware-oracle anchor for the LabWired STM32 I²C onboarding lane. F407 hardware is on the bench; F401 follows as a yaml delta once this path is silicon-verified.
For build/run instructions, see
examples/nucleo-f407-i2c/.
Status at a glance
Live status: the table below is a hand-maintained snapshot. For the authoritative, auto-generated view see the chip conformance scoreboard (level · modelled peripherals · register-match vs silicon) and the tier-1 matrix (per-peripheral pass/fail).
| Aspect | Status |
|---|---|
| Chip yaml | configs/chips/stm32f407.yaml |
| System yaml | examples/nucleo-f407-i2c/system.yaml |
| Reference firmware | examples/nucleo-f407-i2c/ (HAL C firmware — scaffolding in flight) |
| Validation | Simulator-side: AHT20 + BMP280 attach round-trip (config_validation.rs). Hardware oracle pending sensor arrival. |
| Tier | onboarding-in-flight — minimal peripherals declared, I²C silicon-anchor pending |
| Hardware parity | Not byte-parity hardware-validated yet |
Peripherals (from chip yaml)
| Peripheral | Base | Status | Notes |
|---|---|---|---|
| Cortex-M4F | — | ✅ modeled | Thumb-2 + VFPv4 single-precision |
| SysTick | 0xE000E010 | ✅ modeled | System-exception (15) path |
| RCC | 0x40023800 | ✅ modeled | stm32f4 profile |
| GPIOA | 0x40020000 | ✅ modeled | stm32v2 MODER/AFR layout; PA5 = LED |
| GPIOB | 0x40020400 | ✅ modeled | PB6/PB7 default I²C1 SCL/SDA |
| GPIOC | 0x40020800 | ✅ modeled | |
| GPIOD | 0x40020C00 | ✅ modeled | F4-DISCO user LEDs |
| USART2 | 0x40004400 | ✅ modeled | IRQ 38, virtual COM port for debug |
| I²C1 | 0x40005400 | ✅ modeled | IRQ 31. Legacy F1/F2/F4 register layout (SR1/SR2/DR/CR1/CR2/OAR1/CCR/TRISE) |
External devices on I²C1
The reference system attaches two real-silicon devices to I²C1 via
external_devices in examples/nucleo-f407-i2c/system.yaml:
| Device | Address | Protocol shape | Notes |
|---|---|---|---|
| AHT20 | 0x38 | command-stream + BUSY | Temperature + humidity. Models the polling-loop firmware path with a deterministic BUSY counter; CRC8 computed over fixed 25 °C / 50 %RH payload. |
| BMP280 | 0x76 | register-bank + pointer | Pressure + temperature. Chip-ID 0x58, Bosch reference calibration block over 0x88..0xA1, writable ctrl_meas / config, soft-reset honored. |
Two devices on one bus = real address arbitration; two protocol shapes = the I²C state machine is exercised across both repeated-start + multi-byte-read and pointer + sequential-read patterns. This is what "properly onboarded" looks like as a coverage target.
Not yet modeled (commonly expected on F407)
The chip yaml currently does not declare:
- I²C2 / I²C3
- SPI1–SPI3, DMA1 / DMA2, TIM1–TIM14, ADC1/2/3
- CAN1 / CAN2, USART1 / USART3 / USART6 / UART4 / UART5
- USB-OTG FS/HS, SDIO, FSMC, I²S2 / I²S3
- PWR, FLASH controller, RTC, IWDG/WWDG, DCMI, HASH, CRC, RNG, CCM SRAM @ 0x10000000
Firmware that touches any of these registers will hit
MemoryAccessViolation or stall in a polling loop. See
docs/getting_started_firmware.md for
the diagnosis pattern.
Roadmap notes
The F407 lane exists specifically to take STM32 I²C through proper onboarding for the first time — hardware oracle capture, fidelity test against silicon, then F401 receives the same I²C yaml block as a zero-firmware-change delta. Next milestones:
- CubeMX-generated HAL C firmware at
examples/nucleo-f407-i2c/that drivesHAL_I2C_Master_Transmit/Receiveagainst AHT20 and BMP280. - ARM-side oracle scaffolding capturing SR1/SR2/DR/CR1/CR2 register
trace from real F407 silicon via OpenOCD +
stm32f4x.cfg. - Fidelity test in
crates/core/tests/e2e_stm32f407_i2c.rs(gated--ignoreduntil the trace fixture lands). - F401 yaml port — copy the I²C1 stanza, run the same firmware against F401 system manifest, expect identical results.
Once milestones 1–3 land, F407 graduates from "onboarding-in-flight" to
"hardware-anchored" using the same pattern as
docs/boards/nucleo-l476rg.md.