Another valid approach to run the code on the development machine, which is much less invasive for our code base and does not have specific portability requirements, is emulating the whole platform on the host PC. An emulator is a software that can replicate the functionality of an entire system, including its core CPU, memory, and a set of peripherals. Some of the modern virtualization hypervisors for PCs are derived from QEMU, a free software emulator capable of virtualizing entire systems, even with a different architecture from those of the machine where it runs. Since it contains the full implementation of the instruction set of many different targets, QEMU can run the firmware image, which had been compiled for our target, in a process on top of the development machine’s operating system. One of the supported targets that can run ARM Cortex-M3 microcode is LM3S6965EVB, a Cortex-M-based microcontroller that is fully supported by QEMU. Once a binary image has been created using LM3S6965EVB as a target, and properly converted to raw binary format using objcopy, a fully emulated system can be run by invoking QEMU as follows:

$ qemu-system-arm -M lm3s6965evb --kernel image.bin

The --kernel option instructs the emulator to run the image at startup, and while it might sound misnamed, it is called kernel because QEMU is widely used to emulate headless Linux systems on other synthetic targets. Similarly, a convenient debugging session can be started by using QEMU’s built-in GDB server, through the -gdb option, which can also halt the system until our GDB client is connected to it:

$ qemu-system-arm -M lm3s6965evb --kernel image.bin -nographic -S -gdb tcp ::3333

In the same way as with the real target, we can connect arm-none-eabi-gdb to TCP port 3333 on localhost, and start debugging the software image exactly as it was running on the actual platform.

The limit of the emulation approach is that QEMU can only be used to debug generic features that do not involve interaction with actual hardware. The platform emulated is quite specific, and does not match the system layout of a real hardware platform. Nevertheless, running QEMU with a Cortex-M3 target can be a fast way to learn about generic Cortex-M features, such as memory management, system interrupt handling, and processor modes, because many features of the Cortex-M CPU are accurately emulated.

The approach proposed for the definition of test strategies takes into account different scenarios. The idea has been to propose a range of possible solutions for software validation, from lab equipment to tests off-target in simulated and emulated environments, for the developer to choose from in a specific scenario.