19 Testing Firmware on Virtual Hardware
Using Virtual Hardware Without Losing Hardware Reality
19.1 Start With the Firmware Risk
Imagine firmware that passes on a desk but fails when a sensor is noisy, an interrupt arrives early, a bus stalls, or a peripheral resets. Virtual hardware is useful when it exposes that risk before physical boards are scarce or unsafe to modify. The simulation should name the behavior being tested and the evidence needed before code moves to real hardware.
Phoebe’s Why
A virtual I2C pin snaps between logic levels in zero simulated time, because a simulator models a wire as an ideal node with no capacitance. A real I2C bus cannot do that: SDA and SCL are open-drain lines, held high only by an external pull-up resistor, and every pin, trace, and jumper wire the bus touches adds a little parasitic capacitance. Releasing the bus from a driven-low state does not snap it high – it charges the bus capacitance through the pull-up resistor along an ordinary RC curve, and if that curve has not crossed the logic-high threshold by the moment the receiver samples the line, the bit is misread. This is exactly the “pullup values, bus speed” gap this chapter’s own hardware-transfer checklist calls out, and it is invisible to a model with zero bus capacitance by construction.
The Derivation
Releasing an open-drain line lets it charge toward the supply through the pull-up resistor \(R_{pu}\) and bus capacitance \(C_{bus}\):
\[V(t) = V_{DD}\left(1-e^{-t/\tau}\right), \qquad \tau = R_{pu}\,C_{bus}\]
The I2C specification defines rise time as the time to cross from \(0.3\,V_{DD}\) to \(0.7\,V_{DD}\). Solving \(V(t_1)=0.3V_{DD}\) and \(V(t_2)=0.7V_{DD}\) and subtracting:
\[t_r = t_2-t_1 = \tau\ln\!\frac{0.7}{0.3} = 0.847\,R_{pu}\,C_{bus}\]
A receiver samples SDA near the middle or end of the SCL-high phase, so the bus needs \(t_r\) to be comfortably shorter than the minimum high time \(t_{HIGH,min}\) the clock speed allows. This is a settling-before-sampling requirement in the same spirit as the ADC/quantization boundary this chapter’s own “hardware transfer” gate exists to catch – an ideal digital pin has no settling time to violate, so only the bench run can show a rise time eating into the sample window.
Worked Numbers: A Breadboard Pullup Carried Over From The Desk
- Bus capacitance: three virtual-to-bench devices plus breadboard jumper wires, catalog-typical \(C_{bus}=80.0\) pF (well under the 400 pF I2C bus maximum, but well above a compact PCB’s few tens of pF)
- Pullup reused from a slower design: \(R_{pu}=10.0\ \text{k}\Omega\) (a value the chapter’s own “10 kOhm resistor” appears elsewhere in this module as a stock part) gives \(t_r = 0.847\times10{,}000\times80.0\times10^{-12} = 678\) ns
- Fast-mode I2C (400 kHz) allows at most \(t_r=300\) ns: the 678 ns rise time is \(678/300 = 2.26\times\) over the limit, and the maximum pullup that would fit is \(R_{pu,max}=300/(0.847\times80.0\times10^{-3}) = 4.43\ \text{k}\Omega\) – a 2.2 k\(\Omega\) pullup, not 10 k\(\Omega\), is what fast-mode actually needs at this capacitance
- Against the clock itself: fast-mode’s minimum SCL high time is \(t_{HIGH,min}=600\) ns, and \(678\) ns already exceeds that entire window – the line has not even reached the valid logic-high band before the next clock edge is due, a guaranteed misread that a zero-capacitance virtual pin can never reproduce
- The same 10 k\(\Omega\) pullup at standard mode (100 kHz, \(t_r\) limit 1000 ns): it passes comfortably, since \(678\ \text{ns} < 1000\ \text{ns}\) – which is exactly why a value that “worked in Wokwi” or on an earlier 100 kHz board can quietly fail only after a bench build runs the bus faster
19.2 Learning Objectives
By the end of this chapter, you will be able to:
- Define which hardware-programming claims a simulator can support and which claims require physical hardware.
- Build a repeatable virtual circuit that links firmware, pin maps, virtual peripherals, test inputs, and expected observations.
- Use simulated boards and peripherals to exercise firmware logic, state transitions, error handling, and interface assumptions.
- Capture simulation evidence without overclaiming timing, analog, radio, power, or environmental behavior.
- Plan a controlled transfer from simulation to bench hardware and record what must be revalidated.
19.3 Simulate, Then Prove Firmware
Virtual hardware is useful when the team is clear about the claim. It can run firmware against a modeled board, sensor, display, bus, timer, interrupt, or user input before the physical prototype is available. It cannot prove the real board’s electrical margin, analog accuracy, radio range, enclosure behavior, thermal behavior, or battery life. A useful Wokwi, Tinkercad Circuits, Renode, QEMU, Proteus, or custom harness run therefore answers a scoped question such as whether a fault branch executes, whether a pin map matches the intended schematic, or whether a parser survives malformed input.
A strong simulation pass names three things before anyone celebrates a green run: the firmware behavior being exercised, the model boundary, and the bench check that will replace the virtual assumption. That keeps a simulator from becoming a shortcut around hardware truth. For an ESP32 or Arduino-style node, the model may cover GPIO, serial logs, button state, virtual DHT22/BME280 values, and an MQTT mock, while omitting Wi-Fi coexistence, regulator behavior, antenna placement, and sleep current. For an RP2040 or Zephyr target, it may cover I2C/SPI/UART sequencing and reset logic while omitting actual pullups, timing margin, and board variant constraints.
The loop is deliberately conservative. It starts with a design claim, records model scope, builds a reproducible virtual setup, applies normal and fault stimuli, captures observed evidence, and sends unresolved physical claims to hardware transfer. That means a passing simulator run is allowed to move firmware work forward, create reviewable logs, and uncover missing error handling. It is not allowed to replace logic-analyzer traces, oscilloscope measurements, current profiling, sensor calibration, RF testing, or environmental checks when those are the claims under review.
- Good simulation claim: The firmware handles missing sensor data, invalid messages, reset during alarm, or a full command buffer.
- Model boundary: Virtual pins, ideal sensors, simplified bus timing, deterministic inputs, and omitted power/RF/thermal effects.
- Hardware transfer: Repeat the scenario on a real board with serial logs, logic analyzer traces, power measurements, and sensor checks.
19.4 Build Virtual Circuit Test Harness
Treat the virtual circuit as versioned engineering material. For a Wokwi project, keep diagram.json, firmware source, board target, library versions, serial output, and scenario instructions together. For Renode or QEMU, keep the platform description, machine configuration, firmware image, startup script, UART log, and CI command. For Arduino CLI, PlatformIO, or Zephyr builds, keep the board identifier, compile flags, dependency lock state, and simulator-specific setup. The review artifact should be runnable by someone who did not build the demo.
Name the actual interfaces the firmware depends on. A Raspberry Pi Pico or RP2040 simulation may exercise GPIO, PWM, I2C, SPI, UART, timers, and interrupt handling. An ESP32 or Arduino-style node may exercise Wi-Fi/MQTT mock paths, OLED updates, button state, LED state, DHT22/BME280/DS18B20-style sensor values, and serial diagnostics. A useful run includes normal, boundary, missing-device, invalid-value, reset, and rapid-input cases. Each case should state the expected serial line, display state, LED state, message count, timeout branch, or assertion result.
Carry simulator evidence into the same workflow used for physical verification. If the simulation checks an I2C sensor branch, the handoff should name the bench counterpart: pullup values, bus speed, address scan, logic-analyzer capture, and sensor-read timing. If it checks a sleep or watchdog path, the handoff should name current measurement, wake source, reset reason, brownout threshold, and battery-load test. If it checks a gateway service image in QEMU or Renode, the handoff should name boot timing, peripheral availability, network path, log correlation, and target-board rerun. This keeps the virtual circuit from becoming a separate truth source.
- Freeze the pin map. Match virtual pins to the schematic, datasheet pin names, voltage domains, pullups, and connector plan.
- Drive failure paths deliberately. Use absent sensors, wrong I2C address, malformed UART input, full buffers, watchdog reset, and repeated button events.
- Carry the same scenario to the bench. Use a logic analyzer, oscilloscope, current probe, serial logger, RF tool, or calibrated sensor as the physical counterpart.
19.5 Ideal Models Hide Gaps
Most virtual hardware models are intentionally simplified. They may not model pullup resistance, bus capacitance, rise/fall time, ADC noise, oscillator drift, brownout, regulator dropout, interrupt jitter, DMA timing, flash wear, boot strap pins, ESD damage, connector tolerance, or sensor calibration. A clean simulated I2C transaction does not prove a real cable, board layout, or pullup value will survive the bench. A clean UART parser run does not prove level shifting, framing under noise, or connector strain. A successful simulated Wi-Fi publish does not prove antenna placement, roaming, coexistence, or access-point recovery.
This is why the under-the-hood result is a set of transfer questions, not a release claim. If a simulated SPI waveform has the right command order, the bench still needs chip-select timing, voltage level, setup/hold margin, real peripheral response, and noise check. If a simulated sleep path reaches low-power mode, the bench still needs current draw, wake latency, watchdog behavior, and battery-load measurement. If a simulator runs a Zephyr or embedded-Linux image, the target board still needs driver availability, device-tree accuracy, bootloader behavior, peripheral timing, flash partition, and recovery-path checks.
The practical reason to write these limits down is that simulator failures and bench failures have different root-cause classes. A simulator mismatch may be firmware logic, fixture data, library version, build target, or model coverage. A bench mismatch may be schematic, assembly, power integrity, tolerance, environmental condition, instrument setup, or firmware timing. Good evidence separates those categories, updates the model when the bench exposes a wrong assumption, and keeps the simulator useful for regression tests without pretending it measures physical reality.
- Digital state: State machine branch, message parser, debounce behavior, timeout path, reset recovery, and watchdog path.
- Physical state: Voltage, current, timing margin, thermal condition, analog tolerance, RF path, and mechanical access.
- Transfer gap: The exact physical measurement or bench scenario that must follow the simulator run.
19.6 Prerequisites
You should already be comfortable with:
- Specification Sheet Fundamentals: turning part documents into design assumptions and validation actions.
- Hardware prototyping: breadboards, wiring, pullups, decoupling, and basic bench checks.
- Prototyping software: firmware sketches, libraries, serial logs, and build configuration.
- Testing and validation: evidence records, test limits, and the difference between development checks and release validation.
19.7 What This Chapter Adds
The testing-validation chapters discuss simulation tools and validation methods in more detail. This chapter focuses on the design-methodology question: how do you use simulated hardware programming without letting simulation claims drift beyond what the model can prove?
Name the claim
Write down whether the simulation checks firmware logic, pin mapping, protocol sequence, UI behavior, error handling, or documentation.
Know what is virtual
A virtual sensor, board, or bus may behave ideally. Record which timing, analog, power, and environmental effects are outside the model.
Make runs repeatable
Store firmware version, simulator project, virtual wiring, test inputs, logs, waveforms, and expected observations together.
Plan bench validation
Move to physical hardware with a checklist for power, wiring, interface timing, sensor behavior, and any claim simulation could not prove.
19.8 Use Virtual Hardware as Evidence
Virtual hardware is useful when it answers a narrow firmware or integration question. The team names the claim, states what the model includes, builds a repeatable virtual circuit, applies normal and fault stimuli, captures the observed behavior, and carries the same scenario to physical hardware when the claim depends on electrical, timing, analog, RF, power, or environmental reality.
Use the loop introduced in the overview when the firmware depends on board pins, sensors, bus devices, displays, actuators, timers, interrupts, or user interaction. The loop makes simulation a disciplined development activity instead of a quick demo that becomes unreviewable later.
19.9 Choose the Simulator Role
Do not rank simulators in the abstract. Choose the role that matches the evidence you need.
A project that says “tested in Wokwi” or “runs in QEMU” is incomplete. A useful record says what was tested, which model was used, what inputs were applied, what output was observed, and which physical checks are still required.
19.10 Define the Model Boundary
Simulation quality depends on the model boundary. The model boundary describes what the simulator represents and what it leaves out.
Simulation can clear a development gate. Release decisions still need the physical evidence required by the product risk: electrical measurement, timing capture, power profile, environmental test, RF test, production fixture result, or field trial.
19.11 Build a Repeatable Virtual Circuit
A virtual circuit should be treated like source code. It should be reviewable, versioned, and tied to a design assumption.
Build inputs
Record source commit, board target, library versions, compile flags, and simulator-specific configuration.
Pin map
Keep virtual wiring aligned with the schematic, datasheet pin names, board variant, pullup plan, and connector assignment.
Test inputs
Define sensor values, button events, reset points, communication errors, timing windows, and expected serial output.
Run record
Save logs, screenshots, waveform exports, pass/fail notes, and known limitations in the same run folder.
For small projects, a compact checklist is enough:
Simulation handoff:
- design claim: alarm state machine handles normal, warning, and fault states
- firmware: commit id and board target
- virtual hardware: board type, sensor model, display model, pin map
- stimuli: normal sample, high sample, sensor disconnect, reset during alarm
- expected evidence: serial log, LED state, display text, fault counter
- not proven: real sensor accuracy, interrupt latency, current draw, enclosure behavior
- hardware transfer: repeat pin, power, timing, and sensor checks on the bench19.12 Exercise Firmware Behavior
Simulation is valuable because it makes difficult test conditions cheap to repeat. Use it to cover firmware paths that are easy to skip on the bench.
Do not wait for the bench to discover every error branch. In simulation, intentionally remove a sensor, use a wrong bus address, send invalid data, reboot during an operation, and repeat rapid user inputs. Record which faults the firmware handled and which require redesign.
19.13 Interpret Simulation Evidence Carefully
Simulation evidence is strongest when the claim is phrased narrowly.
19.14 Transfer From Simulation to Hardware
The transfer gate prevents a clean virtual run from becoming a false release decision.
19.15 Incremental Examples
19.15.1 Wokwi Alarm State Machine
A first virtual run might use an ESP32 or Arduino Uno in Wokwi with a DHT22 or DS18B20-style temperature input, one LED, and serial logging. The simulation claim is narrow: the firmware enters normal, warning, alarm, and sensor-missing states and prints the expected diagnostic message. The transfer step is also narrow: repeat the state changes on a real board, check the actual sensor wiring and pullup, and confirm the LED and serial output under a bench power limit.
19.15.2 I2C Display and Sensor Boundary
A Raspberry Pi Pico or RP2040 firmware build may use an I2C BME280 or SHT31 sensor model, an OLED display, and a button. The virtual circuit can test the pin map, state transitions, wrong I2C address handling, missing-device timeout, display text, and repeated button input. Before the design can move beyond prototype confidence, the bench run still needs logic-analyzer traces, real pullup values, bus speed checks, display visibility, switch bounce, and current draw in sleep and wake states.
19.15.3 Emulated Gateway Firmware in CI
A gateway or embedded Linux project may run in Renode or QEMU with Zephyr, a Linux image, UART/SPI mocks, scripted startup, and CI logs. The simulation can catch parser failures, service startup order, watchdog behavior, queue overflow, and configuration mistakes before hardware arrives. The hardware-transfer gate must then repeat critical startup and fault scenarios on the target board, measure boot timing and power, verify real peripheral response, and compare gateway logs with packet captures or MQTT broker events.
19.16 Virtual Sensor Node Review
A team is building a small sensor node that reads a digital sensor, displays a status indicator, and sends an event to a gateway. The physical board is not ready, but firmware work can start.
This is enough to keep firmware moving while hardware is delayed. It is not enough to ship the product.
19.17 Try It Now
Rewrite this weak simulation result into a scoped evidence statement:
“The Wokwi project works, so the hardware design is ready.”
A stronger answer should name the firmware behavior, board or simulator model, virtual peripherals, test stimuli, observed logs or waveforms, model limits, and the physical bench checks that still have to pass.
19.18 Separate Virtual/Physical Claims
For each claim, decide whether simulation can support it, hardware must measure it, or both are needed:
- The firmware enters a fault state when the virtual sensor is missing.
- The I2C bus has enough timing margin with the selected pullup resistors.
- The sleep path disables the display before the node enters low-power mode.
For each answer, name the artifact: virtual project, serial log, simulated waveform, logic-analyzer trace, oscilloscope capture, current profile, or bench note.
19.19 Practice Checks
19.20 Common Pitfalls
Virtual peripherals are useful models, not the actual sensor, display, radio, regulator, board, or connector. Check the real part datasheet and bench behavior.
A simulator may make simple connections look safe. Real boards need correct voltage levels, pullups, current limits, boot strapping pins, and variant-specific pin maps.
Normal inputs are not enough. Include missing devices, invalid readings, timeouts, reset events, full buffers, rapid user input, and recovery after faults.
Simulation can exercise timing-related code paths and sleep or wake logic. Real timing margins and current draw require measurement on target hardware.
A shared link or screenshot is easy to lose. Keep the firmware commit, virtual circuit files, test stimuli, expected observations, logs, and model-boundary note with the design notes.
19.21 Summary
Simulating hardware programming helps teams develop embedded firmware before every physical detail is ready. It is strongest when the simulation has a named design claim, a documented model boundary, a versioned virtual circuit, intentional test stimuli, captured evidence, and a hardware-transfer plan. Use simulation to move faster and improve coverage. Use physical hardware to prove the electrical, timing, analog, RF, power, environmental, and manufacturing claims that simulation cannot prove.
19.22 References
- Wokwi Documentation - official browser-based hardware simulation documentation.
- Wokwi Diagram Format - official reference for virtual circuit project files.
- Autodesk Tinkercad Circuits - official learning resources for Tinkercad circuit simulation.
- Renode Documentation - official embedded-system emulation documentation.
- QEMU System Emulation Documentation - official QEMU system-emulation documentation.
- Arduino CLI Documentation - official command-line build and upload documentation for Arduino workflows.
19.23 See Also
- Specification Sheet Fundamentals: convert datasheet limits into model boundaries and bench checks.
- Testing and Validation: decide when a simulator pass is enough for development and when physical evidence is required.
- Simulating Testing and Validation: connect virtual runs to validation workflows.
- Hardware Prototyping: move from virtual wiring to breadboard, bench, and prototype hardware checks.
19.24 What’s Next
| If you want to… | Read this |
|---|---|
| Learn simulation fundamentals in more detail | Hardware Simulation Fundamentals |
| Try browser-based simulator tools | Online Hardware Simulators |
| Explore platform emulation and debug tools | Platform-Specific Emulation and Debugging |
| Connect simulation to validation workflow | Simulating Testing and Validation |
| Move from virtual proof to physical prototype | Hardware Prototyping |
| Previous | Current | Next |
|---|---|---|
| Specification Sheet Fundamentals | Simulating Hardware Programming | Simulating Testing and Validation |
19.25 Key Takeaway
Hardware simulation is useful when it tests wiring, timing, sensor behavior, and firmware logic before physical parts are available. It should reduce risk, not replace bench testing.