Chiprun
Supported boards
Every board Chiprun can run firmware on today. This page is generated from the same registry the service runs on, so it cannot advertise a board that isn't live — but chiprun_list_boards is still the authoritative source for your agent.
| Board key | Chip | Rust target | Engine | Time bounding |
|---|---|---|---|---|
| stm32f4_discovery | STM32F407 | thumbv7em-none-eabihf | renode | exact |
| lm3s6965evb | LM3S6965 (Cortex-M3) | thumbv7m-none-eabi | qemu | approximate |
| mps2_an385 | Cortex-M3 (CMSDK) | thumbv7m-none-eabi | qemu | approximate |
| nrf52840dk | nRF52840 (Cortex-M4) | thumbv7em-none-eabihf | renode | exact |
| sifive_e | FE310 (RV32IMAC) | riscv32imac-unknown-none-elf | qemu | approximate |
Virtual time: exact vs approximate
Every run is capped in virtual CPU time, but the strength of that cap depends on the engine, and we'd rather tell you than let you discover it.
exact — the emulator stops after precisely the requested amount of emulated CPU time. Reproducible across machines regardless of host load. Use these boards when you are testing timing-sensitive behaviour.
approximate — virtual time advances deterministically with instructions retired, but the cap is ultimately enforced by a wall-clock kill. Where a long-running program stops can shift slightly with host load. Fine for functional testing; not what you want for cycle-level timing claims.
Per-board notes
These are the chip-specific traps that cost the most debugging time. Your agent receives them from chiprun_help automatically.
STM32F4 Discovery
stm32f4_discovery
- Print over USART2 (PA2/PA3) at 115200 8N1 — that is the UART captured in the run output.
- Semihosting output is NOT captured. Use the UART.
- Link with --nmagic to avoid a load-address gap that can leave .data uninitialised.
Default 10s of virtual time, up to 60s.
Stellaris LM3S6965 EVB
lm3s6965evb
- UART0 is at 0x4000C000; bytes written to the data register appear in the run output.
- This board is QEMU's canonical Cortex-M target — the Rust embedded ecosystem's stock QEMU example builds and runs here unmodified.
- Virtual-time bounding is approximate on QEMU: the cap is enforced by a wall-clock kill, so a run's exact stopping point can shift with host load.
Default 10s of virtual time, up to 60s.
ARM MPS2 AN385
mps2_an385
- CMSDK UART0 is at 0x40004000, but TX must be enabled first by setting bit 0 of CTRL (0x40004008) — writes to DATA are dropped until then.
- ARM's reference platform rather than a vendor chip: useful for testing generic Cortex-M code without vendor HAL dependencies.
- Virtual-time bounding is approximate on QEMU: the cap is enforced by a wall-clock kill, so a run's exact stopping point can shift with host load.
Default 10s of virtual time, up to 60s.
nRF52840 DK
nrf52840dk
- Drive the UART through UARTE (EasyDMA), not the legacy TXD register at 0x51C — byte writes there are silently ignored.
- EasyDMA can only read from RAM. Pointing TXD.PTR at a string literal in flash transmits nothing; copy it into a RAM buffer first.
- Set ENABLE (0x500) to 8 for UARTE, not 4 (which selects the legacy UART).
Default 10s of virtual time, up to 60s.
SiFive E (HiFive1)
sifive_e
- Link code at 0x20400000 (XIP flash). The mask ROM's reset vector jumps there unconditionally — an image loaded into DTIM at 0x80000000 never executes.
- RISC-V has no vector-table entry that loads the stack pointer, unlike Cortex-M. Your reset path must set sp itself before calling anything.
- UART0 is at 0x10013000: enable TX via txctrl (+0x08) bit 0, then write bytes to txdata (+0x00) once its bit 31 (full) is clear.
Default 10s of virtual time, up to 60s.
Don't see your chip?
Board coverage is driven by what people actually ask for. Tell us your target MCU and use case — requests genuinely shape what gets added next. In the meantime, the limits page covers what a run can and can't do.