Testing

Testing IoT Device Firmware with Simulators: A Developer's Guide

HelpMeTest

HelpMeTest

— 4 min read
Testing IoT Device Firmware with Simulators: A Developer's Guide

Testing IoT firmware is hard. You need hardware that may be scarce, expensive, or not yet manufactured. A device crash takes seconds to reproduce but hours to debug without proper tools. Simulators change this equation — they let you run firmware tests on any CI server without touching real hardware.

This guide covers the main simulator approaches for IoT firmware testing, from unit testing on your laptop to running complete firmware images in QEMU.

Why Simulate Instead of Test on Hardware?

Real hardware testing is necessary but insufficient:

  • Scarce hardware — you may have 2 development boards for a team of 10
  • Slow feedback — flashing firmware + serial console output takes 30-60 seconds per cycle
  • Reproducibility — race conditions manifest differently each run
  • CI/CD — you can't rack up hardware on GitHub Actions

Simulators let you run thousands of test iterations per minute, in parallel, on any machine.

Unit Testing Firmware: The Hardware Abstraction Layer

The key to testable firmware is separating business logic from hardware access. Use a Hardware Abstraction Layer (HAL):

// hal.h — abstract interface
typedef struct {
    void (*gpio_write)(int pin, int value);
    int  (*gpio_read)(int pin);
    void (*uart_send)(const char *data, size_t len);
    int  (*uart_recv)(char *buf, size_t max_len);
} hal_t;

// sensor.c — business logic using HAL
int read_temperature(const hal_t *hal) {
    hal->uart_send("AT+TEMP?\r\n", 10);
    char response[32];
    int len = hal->uart_recv(response, sizeof(response));
    return parse_temperature(response, len);
}

Now you can test read_temperature() with a mock HAL:

// test_sensor.c
#include "unity.h"  // Unity test framework for C
#include "sensor.h"

static char mock_uart_response[32] = "TEMP=23.5\r\n";
static size_t mock_uart_response_len = 11;

static int mock_uart_recv(char *buf, size_t max_len) {
    size_t len = mock_uart_response_len < max_len ? mock_uart_response_len : max_len;
    memcpy(buf, mock_uart_response, len);
    return len;
}

static void mock_uart_send(const char *data, size_t len) {
    // Record what was sent for assertion
    TEST_ASSERT_EQUAL_STRING("AT+TEMP?\r\n", data);
}

hal_t mock_hal = {
    .uart_send = mock_uart_send,
    .uart_recv = mock_uart_recv
};

void test_read_temperature_returns_parsed_value(void) {
    int temp = read_temperature(&mock_hal);
    TEST_ASSERT_EQUAL_INT(23, temp);
}

This runs on any machine — no hardware required.

QEMU for Full Firmware Simulation

QEMU emulates entire microcontroller architectures. You can boot a complete ARM Cortex-M firmware image:

# Run ARM firmware in QEMU (Cortex-M3)
qemu-system-arm \
  -machine lm3s6965evb \
  -kernel firmware.elf \
  -nographic \
  -serial stdio \
  -monitor null

QEMU supports:

  • ARM Cortex-M3/M4 (STM32, LM3S, Nordic nRF)
  • RISC-V (ESP32-C3)
  • AVR (Arduino)
  • MIPS (some routers/IoT gateways)

For automated testing, run QEMU with a timeout and capture output:

#!/bin/bash
<span class="hljs-built_in">timeout 30 qemu-system-arm \
  -machine lm3s6965evb \
  -kernel firmware.elf \
  -nographic \
  -serial file:output.log \
  2>&1

<span class="hljs-comment"># Check output for expected strings
<span class="hljs-keyword">if grep -q <span class="hljs-string">"All tests passed" output.log; <span class="hljs-keyword">then
  <span class="hljs-built_in">echo <span class="hljs-string">"PASS"
  <span class="hljs-built_in">exit 0
<span class="hljs-keyword">else
  <span class="hljs-built_in">echo <span class="hljs-string">"FAIL"
  <span class="hljs-built_in">cat output.log
  <span class="hljs-built_in">exit 1
<span class="hljs-keyword">fi

Renode for Multi-Device Simulation

Renode is more powerful than QEMU for IoT scenarios — it simulates entire networks of devices:

# Renode script to test two devices communicating
emulation CreateMachine "sensor_node"
emulation CreateMachine "gateway"

machine LoadPlatformDescription @platforms/nrf52840.repl
machine LoadBinary @sensor_firmware.elf 0

connector Connect sysbus.radio sysbus.radio

start

# Wait for sensor to send data
sleep 2
pause

# Read UART output
sysbus.uart0 ReadFromOutput

Renode can simulate:

  • Multiple devices communicating over radio/Bluetooth/Zigbee
  • Peripheral timing and interrupts
  • Power consumption modeling

MicroPython Firmware Testing

For MicroPython-based devices (ESP32, Raspberry Pi Pico), you can test most logic directly in CPython with stubs:

# Create stubs for MicroPython-specific modules
# micropython_stubs/machine.py
class Pin:
    IN = 0
    OUT = 1
    
    def __init__(self, pin_num, direction=IN):
        self.pin_num = pin_num
        self.direction = direction
        self._value = 0
    
    def value(self, val=None):
        if val is not None:
            self._value = val
        return self._value

class I2C:
    def __init__(self, id, scl, sda, freq=400000):
        self._responses = {}
    
    def set_response(self, addr, register, data):
        self._responses[(addr, register)] = data
    
    def readfrom_mem(self, addr, memaddr, nbytes):
        return self._responses.get((addr, memaddr), bytes(nbytes))
# test_sensor.py — runs in standard CPython
import sys
sys.path.insert(0, 'micropython_stubs')

import machine
from sensors.bme280 import BME280

def test_reads_temperature():
    i2c = machine.I2C(0, scl=machine.Pin(22), sda=machine.Pin(21))
    # Simulate BME280 register values for 23°C
    i2c.set_response(0x76, 0xFA, bytes([0x65, 0x50, 0x00]))
    
    sensor = BME280(i2c)
    temp = sensor.temperature
    
    assert 22.0 < temp < 24.0, f"Expected ~23°C, got {temp}"

This runs instantly in pytest without any hardware or emulator.

CI/CD Integration

Add firmware simulation tests to GitHub Actions:

name: Firmware Tests

on: [push, pull_request]

jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Install build tools
        run: sudo apt-get install -y gcc-arm-none-eabi cmake

      - name: Install Unity test framework
        run: git submodule update --init lib/unity

      - name: Build and run unit tests
        run: |
          mkdir build && cd build
          cmake -DCMAKE_TOOLCHAIN_FILE=../cmake/arm-none-eabi.cmake ..
          make test_suite
          ./test_suite

  qemu-integration:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Install QEMU
        run: sudo apt-get install -y qemu-system-arm

      - name: Build firmware
        run: make firmware.elf

      - name: Run in QEMU
        run: |
          timeout 60 qemu-system-arm \
            -machine lm3s6965evb \
            -kernel firmware.elf \
            -nographic \
            -serial file:qemu_output.log || true
          grep -q "TESTS PASSED" qemu_output.log

End-to-End API Testing with HelpMeTest

For IoT devices that expose APIs (REST, MQTT-over-HTTP, or device management portals), use HelpMeTest to test the full device management flow:

*** Test Cases ***
IoT Device Reports Telemetry Correctly
    # Test device management API
    ${headers}=    Create Dictionary    Authorization=Bearer ${DEVICE_TOKEN}
    ${response}=   GET    ${API_URL}/devices/${DEVICE_ID}/telemetry
    ...    headers=${headers}
    Should Be Equal As Integers    ${response.status_code}    200
    ${data}=    Set Variable    ${response.json()}
    Should Contain    ${data}    temperature
    Should Contain    ${data}    humidity

Choosing the Right Simulator

Approach Best For Setup Effort
HAL + mock Unit testing business logic Low
QEMU Full firmware boot testing Medium
Renode Multi-device network testing High
CPython stubs MicroPython firmware Low
Docker + ARM Integration testing Medium

Start with HAL mocks for fast unit tests, add QEMU for integration confidence, and use Renode when you need multi-device scenarios.

Summary

IoT firmware testing without simulators is slow, hardware-dependent, and hard to automate. The solution is a two-layer approach: unit test business logic with HAL mocks (no hardware, no simulator), and integration test the full firmware with QEMU or Renode. For MicroPython, CPython stubs give you a free simulation layer with no additional tools.

The result is firmware testing that runs in CI on every commit — giving you confidence before you touch a single hardware device.

Read more