Solutions / Firmware testing
Automated firmware testing on simulated hardware.
A successful build doesn’t tell you whether the device works. Sim86 runs your compiled firmware with its surrounding circuit, so you can test what it does before the next deployment.
The downloadable example uses the TypeScript SDK. For pytest, we recommend the CLI, currently available through closed access. Contact us to join.
Turn a manual check into a repeatable test.
- 01
Bring your firmware
Build for a supported controller using your existing toolchain. Load the compiled firmware into a circuit with the inputs and components your test needs.
- 02
Define the behavior
Apply inputs and check the response: an output changes, a message arrives, or the device recovers from a fault. Make the expected result explicit.
- 03
Run it again
Repeat the controlled scenario after a change. Keep the firmware version, test configuration, and recorded output so a failure has evidence you can inspect.
A test you can inspect
Does the firmware respond when the button is pressed?
Our STM32F405 example mirrors a button input onto an output. The test presses the button, checks that the output goes high, releases it, and checks that the output returns low.
Then it disconnects the input and runs the same firmware again. The assertion catches the missing response. This checks both the device behavior and whether the test can detect a failure.
Get the firmware, test script, and CI workflow ↗Expected behavior in the example
- Button pressed
- Output becomes high.
- Button released
- Output returns low.
- Input disconnected
- The expected response is missing; the test fails.
The healthy and disconnected cases were checked in the local native simulator. The included authenticated cloud SDK workflow has not been run as part of that validation.
Where Sim86 fits among embedded software testing tools.
Use simulation to test compiled firmware interacting with modeled hardware. Keep your unit tests and static analysis, then add behavioral and integration tests that exercise the circuit around your code.
Firmware test automation
Run controlled scenarios in CI and check recorded outputs. The example keeps the firmware hash, configuration, and run evidence alongside its result.
Connected-device behavior
Connect supported controllers over buses or a modeled RF environment. Check the interactions your product depends on.
Explore connected examples ↗Fault injection testing
Change an input or disconnect a signal and check the firmware’s response. Start with the disconnected-button case, then define the faults your product needs to handle.
Know what your simulation proves.
We run simulation models on GPU- and FPGA-accelerated hardware and use physical hardware farms to compare model behavior. Timing and cycle accuracy matter when firmware depends on more than the final output.
Our published ESP32-C3 benchmark compares signals, timing, and CPU-cycle counts for a specific workload. It includes the differences and downloadable evidence. It does not establish accuracy for every controller or certify a product’s safety.
Read the hardware comparison ↗Start with your controller and your failure case.
The web catalog lists the models available in the dashboard. More models and capabilities are available to partners. Contact us to check the peripherals and behavior your test depends on.
We add controllers on demand, free of charge for our users when they ship us a development board. Ask us about your specific controller or component.
Before you start
Can I use pytest?
Yes. We recommend the CLI for pytest workflows. It is currently available to a closed group of users; contact us for access. The SDK is primarily for web dashboards and integrations, and also supports the automation example linked above.
Will the test repeat the same way?
Keep the firmware, models, configuration, seed, and inputs fixed for a repeatable controlled scenario. Live network services can introduce changes outside that setup.
Does this replace testing on physical hardware?
Move suitable firmware checks into simulation after comparing the relevant behavior with your board. Keep physical validation for electrical, RF, environmental, and other behavior outside the model, along with any assurance your product requires.
