The emulated machine provides the execution environment expected by the board software.
Embedded systems / 2025Computer Architectures and Operating Systems · Politecnico di Torino
Secure Timeout System.
A board built in software.
Our team recreated the essential parts of an automotive development board inside QEMU, started FreeRTOS on it, and built an application to test timers, interrupts, and serial communication.
RoleTeam developer
Team5 students
StackC, QEMU, FreeRTOS
TargetNXP S32K358EVB
01 / The challenge
Test embedded software without the physical board.
The course project targeted the NXP S32K358EVB, an automotive development board based on an Arm Cortex-M7 processor. The board was not available as a standard QEMU machine, so the application could not run until we modeled the hardware it expected.
That made the project broader than writing one embedded application. We had to connect three layers: a virtual board, a real-time operating system, and software that exercised the emulated peripherals.
Virtual boardFreeRTOSDriversApplication
02 / Board model
Recreate only the hardware the software needs.
We extended QEMU with the board's memory layout and the peripherals required by the application. This included flash and RAM regions, interrupt-controller configuration, UART communication, and Periodic Interrupt Timers.
Serial output makes startup and application behavior visible from the host.
Periodic timers generate the interrupts used by the application.
The whole system can run and be debugged without physical hardware.
03 / Software
Bring FreeRTOS up on the emulated board.
The software side includes startup code, a linker script, peripheral drivers, and the FreeRTOS configuration. Together they prepare memory, start the scheduler, and connect timer interrupts to the application.
The Secure Timeout System uses separate tasks to monitor activity, simulate events, and handle alerts. Hardware timers provide periodic signals, while UART output shows how the tasks and events behave during a run.
PIT timerInterruptFreeRTOS taskSystem eventUART output
04 / Reproducibility
Make a complex toolchain repeatable.
The repository keeps QEMU and FreeRTOS as explicit dependencies and provides Make targets for the main workflows: building the emulator, compiling and running the application, or starting a debug session for GDB.
A detailed setup guide records the board model, memory map, peripherals, build steps, and project decisions. This matters because embedded projects are difficult to review when the original environment cannot be recreated.
Practical result
A developer can build, run, and inspect the system on a Linux machine without access to the NXP evaluation board.
05 / Boundaries
Useful emulation, with clear limits.
The virtual board models the parts needed by this project; it is not a complete reproduction of every S32K358 peripheral or every electrical behavior of the physical device. Results from QEMU still need hardware validation before they can support a real automotive deployment.
The team also investigated adapting FreeRTOS memory-protection support from Cortex-M4 to Cortex-M7. The repository documents the required changes and processor errata, but correctly describes the full MPU implementation as work in progress.