I²C and SPI simulation on your real topology
Prev. Bloomberg · Gyfted. Systems and simulation infrastructure — the engine that runs your firmware against the circuit.
Bus bugs are rarely in the MCU reference manual. They are in which chip sits on which bus with which address and CS. Simulation only helps when those facts come from the schematic.
What you can see before probes exist
Enumeration failures, NACKs, wrong addresses, CS polarity/GPIO mistakes, stretch and t_HIGH contracts — with decode instead of a logic analyzer on a half-built board.
Tied to the netlist, not a virtual shield
Attachments come from discovered buses in your design. A hand-maintained “shield” that drifts from the schematic trains drivers on fiction.
When timing is the bug
Clock stretch and master timeouts deserve their own deep dive — see the I²C timing topic and the design-partner post-mortem for a concrete t_HIGH failure.
u4_bmp280: HIP.BMP280 @ spi3
Cs => gpioPortA@15HardLabs
Send us your design. We'll send you a simulator.
We build a board simulator from your netlist, schematic, and BOM, run your real firmware against it, and fail CI when pinmux, buses, or timing contracts break.
- A working simulator of your board, built from netlist, schematic, and BOM.
- Peripheral models attached so your firmware can talk to the board.
- A setup that runs your real firmware binary — no rewrite required.
Related
- I²C clock stretching
Diagnose I²C clock-stretch and t_HIGH violations before fab. Why STM32 masters and slow sensors disagree — and how simulation catches it early.
- Firmware-in-the-loop
Firmware-in-the-loop against your netlist — not stubs. Run unmodified .elf images on MCU simulation with board-aware I²C/SPI models and CI assertions.
- The I²C Timing Bug We Caught Four Weeks Before Fab
- BMP280 model
HardLabsAll topics