When no board is free, or in a CI pipeline, the firmware image can run in QEMU (qemu-system-arm 4.1 or later) on the engineer's machine: software-in-the-loop runs with semihosting output in the Debug Console, and debugging through QEMU's GDB stub.
Run and debug
- Run in Emulator runs the active image in QEMU until it exits through semihosting, with its output in the Debug Console. In a launch configuration, Run Firmware in Emulator does the same.
- Debug in Emulator, or the snippet Embedded: Debug Firmware in Emulator, starts QEMU halted under its GDB stub, resets it through its monitor and debugs the image with GDB, with the same debug views as a session on a probe.
In launch.json, "target": "emulator" and an optional "machine" do the same, and a Cortex-Debug configuration with servertype qemu also runs:
{
"type": "ni-embedded",
"request": "launch",
"name": "Debug Firmware in Emulator",
"target": "emulator",
"machine": "netduinoplus2",
"runToEntryPoint": "main"
}Which machine is used
The machine is chosen from what QEMU's own documentation states for the device and what the installed QEMU lists (-machine help): the STM32F405, F205, F100 and L475, two Stellaris parts and the nRF51.
QEMU does not emulate the STM32F407. Such a device gets a generic Cortex-M board, or a machine you name such as netduinoplus2 (an STM32F405), only after you accept a message that its peripherals and memory map are not the chip's. The Debug Console repeats this when the session starts.
What the emulator does not model: the emulated chip's UART output is not shown, QEMU has no DWT (so the cycle stopwatch and benchmark counters report no counter), and there is no SWO or RTT.
State
Run in Emulator is verified against real QEMU 9.1.1 on macOS with a hand-built STM32F405 image of a few dozen bytes on the netduinoplus2 machine: launch halted under the GDB stub, reset through its monitor, run to a semihosting exit. The machine choice is tested on recorded -machine help output of QEMU 9.1.1. Debug in Emulator itself has not run with GDB in a verified audit. Separately, debug sessions against QEMU 8.2.2's GDB stub with gdb-multiarch 15.1 on Linux were used to verify later views (memory windows, set-up scripts, ORTI, Heap and Stack, the buffer graph, the release comparison). Not verified: a real firmware image, QEMU on Windows, versions other than those named, and a CI pipeline running it.