Solutions / Fault injection
Fault injection testing for the behavior you hope never happens.
An input disappears. A radio frame does not arrive. Your firmware still has to respond. Introduce a controlled fault in Sim86, inspect the result, and keep a test you can run after the fix.
A reproducible starting point
Same firmware. One disconnected input.
Our STM32F405 sample mirrors a button input onto an output. With the normal wiring, the output follows the button. Disconnect the input and the expected response disappears.
The test catches that missing response. This proves that the assertion detects this wiring fault; it does not claim that the sample firmware recovers from it. For your product, define the recovery behavior as a separate expectation.
Download the firmware and test files ↗Make the failure explainable.
- Run the healthy circuit and check the expected response.
- Disconnect the input while keeping the firmware unchanged.
- Run the assertion again and confirm that it fails.
- Keep the firmware hash, configuration, and output with the result.
Both cases were checked in the local native simulator. The guide also provides an SDK cloud workflow; that authenticated workflow was not run as part of this validation.
Choose the fault your firmware needs to handle.
Missing input
Change a connection in the circuit and check whether the firmware detects the missing signal or produces the expected fallback behavior. Start with the downloadable button test.
Degraded radio conditions
Vary modeled path loss, noise, and overlapping transmissions in an RF Environment. Inspect reception outcomes and the response of firmware on supported radios.
Read the RF controls ↗Unexpected Wi-Fi frames
The SDK can schedule exact or deliberately malformed 802.11 frames. They pass through the modeled radio environment, so reception still depends on the configured conditions.
Inspect frame injection ↗Define what a good recovery looks like.
A fault is only useful as a test when you know what should happen next. Should the device report an error, retry within a deadline, or enter a defined fallback state? Turn your product’s requirement into an observable check.
Keep the firmware, models, seed, configuration, and inputs fixed to repeat a controlled scenario. Save the exact fault and its timing. Live Internet services remain outside that repeatable setup.
Keep the regression test after the fix.
Use recorded signals, logs, or frame outcomes to assert the expected response. The firmware-testing guide shows how to keep evidence and fail a CI job when an assertion fails.
For pytest, we recommend the CLI, currently available through closed access. The SDK is primarily for custom web dashboards and integrations, and also supports the example automation.
Check that the model covers the failure.
Sim86 runs models on GPU- and FPGA-accelerated hardware. Our hardware farms help us compare model behavior with physical devices, but each fault test still depends on the specific controller, peripheral, and modeled behavior.
These examples cover simulated wiring and radio-frame conditions. They do not demonstrate voltage glitching, laser injection, physical electromagnetic attacks, or safety certification. RF frame simulation does not calculate modulation waveforms.
Use the hardware benchmark procedure to plan a comparison for your scenario. Its published ESP32-C3 measurements do not validate RF fault behavior.
