DEV Community

Hedy
Hedy

Posted on

How to simulate STM32?

#stm32 #stm32f4discovery #nucleo #simulate

Short version: there’s no “official” full simulator inside STM32CubeIDE. You’ve got a few good paths depending on what you want to test:

1) Algorithm-only (fastest, no hardware)

Use host unit tests to exercise your HAL-free logic.

  • Extract pure C/C++ code (no HAL calls).
  • Test with Unity/CMock/Ceedling or GoogleTest on your PC/CI.
  • Great for state machines, filters, parsers, protocol logic.

2) CPU instruction simulators (run code, limited peripherals)

  • SEGGER Embedded Studio (free for non-commercial) – ARM simulator: runs Cortex-M binaries, basic I/O via semihosting; peripheral emulation is limited.
  • Arm Keil MDK uVision simulator: historically supports Cortex-M simulation with some peripherals on certain device packs (coverage varies). Use these when you mainly care about core code flow, RTOS scheduling, and cycles—not detailed peripherals.

3) Full-system emulation (best balance for firmware + peripherals)

  • Renode (free, cross-platform): Emulates many STM32 boards (e.g., F4/Lx). You can run your .elf, step code, log memory-mapped registers, and script peripherals (UART, SPI/I²C devices, GPIOs, timers). Nice for CI and automated tests.
  • QEMU forks for STM32: Possible, but STM32 peripheral coverage is spottier than Renode; pick a fork that supports your chip.

Minimal Renode workflow

  1. Build your firmware in Debug (-Og -g3) targeting a supported board (e.g., STM32F4-Discovery).
  2. Create a Renode script (e.g., stm32f4.resc): 
using sysbus mach create "stm32f4" machine LoadPlatformDescription @platforms/cpus/stm32f4_discovery.repl sysbus LoadELF @build/firmware.elf showAnalyzer sysbus.usart2 start
Enter fullscreen mode Exit fullscreen mode
  1. Launch: renode stm32f4.resc You’ll see UART output in the analyzer window, can set breakpoints, inspect regs, etc.

4) Schematic-level simulation (firmware + virtual electronics)

Proteus VSM: Drag-and-drop an STM32, sensors, LCDs, op-amps; load your .hex/.elf; step code while the circuit runs. Great for teaching, demos, and early HW/SW co-design. (Coverage depends on your exact MCU/peripherals license.)

5) Model-based / HIL & PIL (control/algorithms)

  • MATLAB/Simulink support packages for STM32/Nucleo: do Processor-in-the-Loop (PIL) or External Mode to validate generated code against the target—more “run on real board” than simulation, but excellent for verifying models and timing.
  • Hardware-in-the-Loop (HIL) with your dev board + sensor emulators for near-real tests.

Which to choose?

  • I just want to verify my algorithms/filters/RTOS tasks: Host unit tests (+ maybe SEGGER/Keil simulator).
  • I need UART/SPI/I²C/GPIO behavior without a board: Renode first; Proteus if you want a schematic view.
  • I want a virtual lab with sensors/displays: Proteus VSM.
  • I’m in a control/Signal-Processing flow: Simulink PIL/External Mode.

Tips for smooth simulation

  • Abstract HAL: wrap hardware access (GPIO/UART/SPI) behind interfaces so you can swap in fakes/mocks on PC and real drivers on target.
  • Deterministic timing: use a tick source you can control in sim; avoid HAL_Delay in core logic.
  • UART visibility: print key state to UART (Renode analyzer captures it), or use semihosting logs on CPU simulators.
  • CI ready: run Renode headless to regression-test every commit.

Top comments (0)