Eindhoven University of Technology MASTER Software ... · J.J.M.J.P (Jasper) Meens (Vanderlande, Veghel) Eindhoven, July 2019. Abstract ... for Embedded devices paving its way into

Eindhoven University of Technology

MASTER

Software emulation of STM32 controller for virtual embedded design/test environment

Joshi, C.V.

Award date:2019

Link to publication

DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

https://research.tue.nl/en/studentthesis/software-emulation-of-stm32-controller-for-virtual-embedded-designtest-environment(4aadaf1f-460e-4593-bda9-449e8037cf23).html

Software Emulation ofSTM32 Controller for

Virtual EmbeddedDesign/Test Environment

Master Thesis

Author:Chandrika V Joshi

A thesis submitted in fulfillment of the requirementsfor the degree of Master of Science

in theSystem Architecture and Networking Research GroupDepartment of Mathematics and Computer Science

Supervisors:dr.ir. Reinder J.Bril

dr.ir. P.H.F.M (Richard) Verhoevenir. J.J.M.J.P (Jasper) Meens (Vanderlande, Veghel)

Eindhoven, July 2019

Abstract

Integrating the emulated Hardware into the embedded test environment facilitates iterative andmodular testing of Embedded SoftWare (ESW) at the initial phases of the ESW DevelopmentLife Cycle (EDLC). Emulation technology eliminates the dependency on hardware and facilitatesESW testing to identify the defects in the early stages of ESW Development. Hardware emula-tion has been around in the industry for testing the hardware design using Verilog & hardwaredesign simulators like HILO. Significant amounts of hardware design testing carried out before thefabrication of hardware chips has proven to be cost effective and saving effort for the hardwaredesign and development [40]. Recently, there have been advancements in the software emulationfor Embedded devices paving its way into Embedded SDLC [1].

In this thesis, a detailed study is conducted on the existing verification techniques and theirdrawbacks with respect to the embedded system testing. Based on this study, an implementationof the STM32f407ve controller emulation is carried out on an open-source platform by FabriceBallard-QEMU [9]. QEMU provides essential APIs to develop and use the emulated hardwareboard to achieve virtualization. Initial work has been carried out by freelancers on QEMU tobuild various boards, which have been referred for this project to develop the specific board ofSTM32 for the test environment at Vanderlande. The development includes adding the hardwaremachine emulation of STM32 to the QEMU with the emulated peripherals clock control and GPIO.

The emulated hardware has been examined to understand the behavior and performance con-cerning the functional testing, time-based testing, CPU load as compared to the real hardware.This thesis initiates a view towards utilizing the virtual test environments for Embedded SDLCover traditional test setups.

Software Emulation of STM32 Controller for Virtual Embedded Design/Test Environment iii

Preface

During my thesis, I have received a lot of support from my friends, family, and colleagues. I wouldlike to thank all of them and dedicate a few lines to some people in particular.

First of all, I would like to thank my supervisors at Vanderlande Erik V.Dartel and JasperMeens for all the guidance and support. The 6 months I spent at Vanderlande was great learn-ing experience for me. The constant support & feedback from my colleagues helped me to bemotivated. I would also like to thank Carlo Veld and Ad van den Langenberg at Vanderlandefor their technical support. They have been an enormous source of motivation and inspiration tolearn, looking at their technical expertise and down to earth attitude. It was a pleasure workingat Vanderlande for all the discussions on the insightful topics I had. I had the privilege of workingwith some of the best minds, who inspired me further.

I am grateful to my supervisors at TU/e, Professor Dr. Reinder.J. Bril for the quick responsesto my emails, technical insights and guiding me in the right direction in times of confusion. Ialways felt positive working with him. He took extra effort to push me to shape my thesis well interms of implementation and report. I would also like to thank my mentor dr. Richard Verhoevenfor helping me get started with the assignment, helping me with technical difficulties during theimplementation of the project. My discussions with him and his feedback on the technical frontwere essential for the thesis.

From the non-academic side of my life, I would like to thank my friend Nitin for constantsupport and encouragement. I had the utmost joy in sharing and discussing the assignment withhim outside work. My family, my parents, and in-laws, my brother for being there for me andunderstanding my ambitions, I am forever grateful.

Lastly, I would like to thank my husband Bhargav, for his unbiased support and love. I hadquite many suggestions on how to improve the project and be creative with my assignment in thetechnical front. Thank you for being a part of this journey.

Chandrika JoshiVeghel, June 2019

Software Emulation of STM32 Controller for Virtual Embedded Design/Test Environment v

Contents

Contents vii

List of Figures ix

List of Tables xi

Listings xiii

List of Abbreviations xv

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Objectives and Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.7 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Project Context 92.1 Literature Survey of the existing verification techniques . . . . . . . . . . . . . . . 9

2.1.1 Conventional in-the-loop methods . . . . . . . . . . . . . . . . . . . . . . . 102.2 A study on current test environment . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Lack of embedded environment in the simulation . . . . . . . . . . . . . . . . . . . 16

2.3.1 Difference between the resources of host PC and target hardware . . . . . . 172.4 Chapter Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Preliminaries 213.1 Virtualization Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Virtual machine reference model . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Rules for virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3 Types of virtualizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.1 Privileged and non-privileged instructions . . . . . . . . . . . . . . . . . . . 233.4 Concept of Simulated time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4.1 Simulated time and OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.5 Chapter Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Emulator Evaluation 274.1 Literature survey on emulators and emulator selection . . . . . . . . . . . . . . . . 28

4.1.1 Design Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.1.2 Emulator Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1.3 Motivation for QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Software Emulation of STM32 Controller for Virtual Embedded Design/Test Environment vii

CONTENTS

4.2 Chapter Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Implementation of the STM32F407 Emulation 335.1 Emulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1.1 Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.2 Bare-metal Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2.1 Binary File development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3 QEMU detailed study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.3.1 Optimizations Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.3.2 QEMU workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3.3 QEMU APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.4 Development of STM32 modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.4.1 Adding STM32 argument to machine list in QEMU . . . . . . . . . . . . . 445.4.2 Cortex-M4 Processor and Memory Emulation . . . . . . . . . . . . . . . . . 455.4.3 Clock Control Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.4.4 General Purpose Input/Output Emulation . . . . . . . . . . . . . . . . . . . 50

5.5 Collective overview of clock behavior for GPIO and processor . . . . . . . . . . . . 545.6 Chapter Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 Performance Analysis and Evaluation of the Emulated platform 576.1 Modularity test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.2 Functionality test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.2.1 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.3 Scalability test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.3.1 CPU Usage: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.3.2 Memory Usage: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.4 Real-Time performance test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.5 Other tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.6 Chapter Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7 Conclusions 677.1 Outcomes of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.1.1 Recommendations to use emulated hardware boards on hypervisors . . . . . 697.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Bibliography 71

Appendix 75

A Development in QEMU 75A.1 QEMU Machine list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75A.2 Binary file Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

B Implementation of the STM32 hardware 78B.1 Reset and Clock control Register map . . . . . . . . . . . . . . . . . . . . . . . . . 78B.2 GPIO register map with reset values . . . . . . . . . . . . . . . . . . . . . . . . . . 81B.3 Implementation of Clock Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

C Performance Analysis 89C.1 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

viii Software Emulation of STM32 Controller for Virtual Embedded Design/Test Environment

List of Figures

1.1 Relative cost to fix bugs , based on time of detection [46] . . . . . . . . . . . . . . . 31.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Reference model for the RTS [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 EDLC with problem area highlighted and simulation techniques used at specific phases. 112.3 Various simulation types used in ESW testing . . . . . . . . . . . . . . . . . . . . . 112.4 Depiction of sorter system with ECUs, switches, parcel and conveyors . . . . . . . 132.5 plant model as a sub-system in complete test setup (a) Sub-systems of plant model (b) 152.6 General Embedded Software Architecture of STM32 [19] . . . . . . . . . . . . . . . 162.7 HAL layer in the ESW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.8 Summary of ARM and x86-64 architecture [12] trends. . . . . . . . . . . . . . . . . 18

3.1 Typical architecture of a Virtual machine on host machine . . . . . . . . . . . . . . 22

4.1 General Test environment with Speedgoat [50] . . . . . . . . . . . . . . . . . . . . . 274.2 Improvement in the EDLC after the introduction of virtual hardware in unit and

integration test phases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.1 System architecture for STM32F407xx devices [52] . . . . . . . . . . . . . . . . . . 335.2 Compiler stages to generate a binary file [20] . . . . . . . . . . . . . . . . . . . . . 365.3 Depiction of Guest and Host machine view perspective . . . . . . . . . . . . . . . . 385.4 Working of Binary Dynamic Translator and Tiny Code Generator [44] . . . . . . . 395.5 A depiction of QEMU code flow (Source: Stack Overflow, verified in GDB) . . . . 405.6 A depiction of Binary Dynamic Translation [44] . . . . . . . . . . . . . . . . . . . 415.7 Complete Development process involved in development of STM32F407 emulation . 435.8 Memory mapping of STM32F407 memory space with remapping [52] . . . . . . . . 455.9 Basic clock circuitry for the STM32F407 with ARM processor [29] . . . . . . . . . 475.10 Complete QEMU timer diagram [13] . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1 Plot of number of QEMU instances v. the % of CPU share of one instance when10 instances are running parallelly. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.2 Plot of number of QEMU instances v. the % of total CPU capacity shared amongQEMU instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.3 Plot of number of instances v. average CPU Load . . . . . . . . . . . . . . . . . . . 636.4 Different states of processes in Linux OS [33] . . . . . . . . . . . . . . . . . . . . . 646.5 Plot of number of QEMU instances v. average latency with minimum and maximum

values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.6 Plot of number of QEMU instances v. average latency and average CPU load . . . 65

A.1 Vector table in elf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76A.2 Memory layout in elf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

B.1 RCC register map and reset values [52] . . . . . . . . . . . . . . . . . . . . . . . . . 78

Software Emulation of STM32 Controller for Virtual Embedded Design/Test Environment ix

LIST OF FIGURES

B.2 RCC register map and reset values contd. [52] . . . . . . . . . . . . . . . . . . . . . 79B.3 Register RCC CR with definition of each bit [52] . . . . . . . . . . . . . . . . . . . 80B.4 Register RCC CFGR with definition of each bit [52] . . . . . . . . . . . . . . . . . 80B.5 STM32F407 AHB1 high speed bus clock enable register (RCC AHB1ENR) [52] . . 80B.6 GPIO register map with reset values [52] . . . . . . . . . . . . . . . . . . . . . . . . 82B.7 GPIO register map with reset values contd. [52] . . . . . . . . . . . . . . . . . . . . 83B.8 Moder Register of STM32F407 [52] . . . . . . . . . . . . . . . . . . . . . . . . . . . 84B.9 IDR Register of STM32F407 [52] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84B.10 ODR Register of STM32F407 [52] . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

x Software Emulation of STM32 Controller for Virtual Embedded Design/Test Environment

List of Tables

4.1 A collation of emulator evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Peripheral names and Boundary addresses to be specified for memory emulation . . 465.2 Different clock settings that can be used for STM32F407 functioning . . . . . . . . 48

6.1 Test case scenarios to test CPU Cortex-M4 and GPIO in combination . . . . . . . 59

Software Emulation of STM32 Controller for Virtual Embedded Design/Test Environment xi

Listings

5.1 Startup code with definition of the Reset handler and global data initialization . . . 365.2 Snippet of the linker code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.3 Command to invoke QEMU machine . . . . . . . . . . . . . . . . . . . . . . . . . . 395.4 Code to employ mutex on thread running the CPU to allocate resources to the ded-

icated CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.5 Skeleton code structure to define a custom machine . . . . . . . . . . . . . . . . . . 435.6 Code snippet of details added in machine description file to add STM32F407 to

QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.7 Code snippet for memory emulation . . . . . . . . . . . . . . . . . . . . . . . . . . 465.8 Code snippet to create clock for GPIOs . . . . . . . . . . . . . . . . . . . . . . . . . 505.9 Code to assign clock frequency to GPIOs requested by the application logic . . . . . 515.10 Read function for the application logic requests for configuration . . . . . . . . . . 525.11 Definition of GPIOs and their state in the stm32f407xx gpio.c . . . . . . . . . . . . 535.12 Code snippet of MODER, IDR and ODR emulation . . . . . . . . . . . . . . . . . 536.1 Code in the QEMU source code avoid segmentation faults for missing peripherals of

target hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.2 Simple application code to test peripherals implemented . . . . . . . . . . . . . . . 596.3 Application code to toggle multiple pins of same port A . . . . . . . . . . . . . . . . 596.4 Application code to toggle multiple pins of two different ports A and E . . . . . . . 606.5 Application code to toggle multiple pins of two different ports A and E . . . . . . . 60A.1 QEMU Machine list under ARM architecture along with newly added STM32 machine 75B.1 Definition of RCC CR,RCC CFGR and RCC AHB1ENR in stm32f407xx rcc.c [52] 80B.2 Helper Function to recalculate the Output frequency based on pre-scaler by applica-

tion logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84B.3 Register implementation to set up clock tree for RCC CR, RCC CFGR,RCC PLLCFGR 85C.1 Test for Modularity showing QEMU unimplemented register warnings . . . . . . . 89C.2 Test case 1 output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90C.3 Test case 2 output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93C.4 Test case 3 output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96C.5 Test case 4 output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Software Emulation of STM32 Controller for Virtual Embedded Design/Test Environment xiii

List of Abbreviations

ABS Anti-lock Braking System

API Application Program Interface

BB Basic Block

BDT Binary Dynamic Translator

CAN Controller Area Network

CISC Complex Instruction Set Computer

CMSIS Cortex Micro-controller Software Interface Standard

CPU Central Processing Unit

EABI Application Binary Interface

ECU Electronic Control Unit

EDLC Embedded Development Life Cycle

EmSW Emulation Software

ESW Embedded Software

FPGA Field Programmable Gate Array

FPU Floating Point Unit

FVP Fixed Virtual Platform

GPIO General Purpose Input Output

GUI Graphical User Interface

HAL Hardware Abstraction Layer

HIL Hardware-In-the-Loop

HSE High Speed External

HSI High Speed Internal

ISA Instruction Set Architecture

ISR Interrupt Service Routine

IT Integration Testing

IVT Interrupt Vector Table

MBD Model Based Development

MCU Micro-Controller Unit

MIL Model-In-the-Loop

OS Operating System

Software Emulation of STM32 Controller for Virtual Embedded Design/Test Environment xv

LISTINGS

OVP Open Virtual Platform

PC Personal Computer

PCB Printed Circuit Board

PIL Processor-In-the-Loop

PLC Programmable Logic Control

PLC Programmable Logic Control

PLL Phase Locked Loop

PWM Pulse Modulation Width

QEMU Quick Emulator

QMP QEMU Machine Protocol

QOM QEMU Object Model

RAM Random Access Memory

RISC Reduced Instruction Set Computer

RTCS Real Time Computer System

RTOS Real Time Operating System

RTS Real-time Systems

RTSW Real Time Software

RTSW Real Time SoftWare

SDLC Software Development Life Cycle

SIL Software-In-the-Loop

SOC System On Chip

SUT System Under Test

TB Translation Block

TCG Tiny Code Generator

UT Unit Testing

VM Virtual Machine

VMM Virtual Machine Monitor

XIL X-In-the-Loop

xvi Software Emulation of STM32 Controller for Virtual Embedded Design/Test Environment

Chapter 1

Introduction

Embedded systems are systems that are integral components of larger systems, which are used tocontrol and/or directly monitor that system using special hardware devices [31]. New productsin the field of embedded systems technology are emerging at a rapid rate leading to state-of-the-art design requirements. The embedded devices and applications are omnipresent in thecomputer-controlled world. Even simple embedded devices come with multi-core processors andcomplex software structures. Embedded devices are becoming complicated due to the increasingdemand in time and resource constraints. Embedded technology in today’s world is not only drivenby critical requirements but also caters to performance-aware embedded machine designs. Thefact that embedded systems can purvey to extreme time and resource-constrained requirements,make them popular in today’s tech-savvy world. More and more research is being carried out tocreate performance-aware systems to improve user experience such as multimedia technology in theautomotive industry. With progress in embedded technology, the time spent in the developmentand verification of these systems rises substantially.

Real-time embedded systems are highly resource-constrained and are used for safety-criticalapplications. The reliability1 and availability2 of the embedded applications cannot be comprom-ised in such systems, for instance, mechatronic3 automobiles and medical applications. Severalrigorous verification techniques are being used currently to deploy fail-safe and robust systems tothe users.

Studies have shown that Embedded SoftWare4 (ESW) has high defect densities: 13 majorerrors per 1000 lines of code on an average during development [30]. It is estimated that 40% ofthe total development cost of the software is spent on the verification of the software and defectfixes/defect elimination is given higher importance than meeting the project deadlines. Unlike non-embedded software, real-time embedded applications are tested for their deterministic behavioron the physical embedded devices5. Physical embedded devices such as an Electronic ControlUnit (ECU) have their own hardware development life cycle parallel to the ESW DevelopmentLife Cycle (EDLC) and EDLC is highly dependent on the physical embedded devices for testing.Embedded developers trade-off the requirement of embedded devices during early testing stagesfor faster testing techniques such as simulation-based testing to be independent of the hardware.This trade-off results in high defect densities due to the lack of hardware-specific environment,adding to the development costs of ESW during defect fixes.

Due to expenses incurred as a result of non-embedded testing setups and time-to-market pres-sure, testing in the early stages of the development phase with embedded devices is becoming

1Continuity of correct service (expressed as a period of time)2Readiness for correct service ( expressed as a probability)3Technology combining electronics and mechanical engineering.4The software that is developed and deployed on embedded controllers to control the behavior of Mechatronic

Systems5An embedded system is a controller with a dedicated function within a larger mechanical or electrical system,

often with real-time computing constraints. It is embedded as part of a complete device often including hardwareand mechanical parts.

Software Emulation of STM32 Controller for Virtual Embedded Design/Test Environment 1

CHAPTER 1. INTRODUCTION

mainstream. The ESW development is handled in phases by specific developers for each phaseand a verification process is probed to test the ESW at every stage. Probing verification activityat every stage of software development with hardware when the ESW is not completely developedis challenging to carry out. Modern testing techniques involve Model-Based Development (MBD)which is a simulation based testing, to increase the testing abilities of the embedded systems. TheMBD aims at creating a mathematical, virtual representation of the real world to address theproblems associated with designing complex control systems. The purpose of MBD is to detecterrors, to achieve a higher degree of automation and to save costs by using models as importantartifacts in the development process.

However, the MBD does not completely satisfy the requirement of real-time embedded testsetups. The MBD does not cater to the deterministic and hardware-specific behavior of thephysical device like the ECU. A verification technology that is simulation-based but also providesthe hardware-specific behavior is the need of the hour. In recent years, emulation has been usedextensively to mimic the real hardware and to test software such as Android for mobile applications.Emulation takes simulation to the subsequent level to provide a real-time environment to theESW by imitating the real hardware in terms of memory, I/O, processor, and its architecture.This report is focused on analyzing the advent of the emulation into the embedded systems andthe viability of the emulation techniques in the real-time EDLC. It is also attempted to emulatereal hardware platform to analyze the behavior and to measure the performance of the emulatedplatform. The performance results of the emulated platform presented in this report show animprovement in the ease of phase-based testing without physical hardware.

This thesis is carried out at Vanderlande Industries B.V in Veghel. Vanderlande Industriesis a global market leader in logistic process automation at airports, parcel handling market andprovides solutions for process automation in warehousing. The current test setups at the companyextensively use Hardware-In-the-loop(HIL)6 testing to successfully test the ESW and are lookingfor an efficient technology to conduct early tests using emulation to avoid snowballing of the defectsat the end phase.

1.1 Background

ESW testing is highly dependent on the hardware availability and execution environment. Embed-ded software developers are under constant pressure to reduce design time often in the presence ofcontinuously changing specifications. In such circumstances, the developers turn towards high-levelmodels to achieve rapid prototyping and trade-off the real-time behavior facilitated by physicalhardware. The ESW verification with physical hardware is pushed towards the end of EDLCimplanting more and more errors only to be surfaced during HIL testing that leads to remodelingof the ESW architectural design or its specifications. A HIL is typically a hardware controller in atest environment such as an ECU on which the ESW runs to control the sub-systems or hardwaresuch as an actuator. HIL simulation shows how a controller responds, in real-time, to realisticvirtual stimuli. Figure 1.1 shows a bar chart of increased cost in defect fixes at each stage ofsoftware development.

6 A HIL is a test setup where an ESW executes on a hardware controller or ECU interacting with controlledsystem that also runs on a Real-Time System.

2 Software Emulation of STM32 Controller for Virtual Embedded Design/Test Environment


Figure 1.1: Relative cost to fix bugs , based on time of detection [46]

To obtain more control over the ESW performance and to analyze the root cause of the defectsat the early stages of EDLC, it is better to invest in sophisticated verification methods of Embeddedsystems.

1.2 Problem statement

During the analysis of the current testing techniques of the embedded systems, it is observedthat one of the major problem faced is the evaluation of hardware-software co-design. Mosttimes, software integration and debugging could start much earlier, and software developmentcould proceed faster if only a hardware prototype could consistently be available earlier in thedevelopment cycle.

Secondly, even if the physical hardware is available in the earlier phases, the software is notmature enough to run on the full-fledged hardware. The ESW is a group of heterogeneous functionsinterfacing together. To develop each function an expert(developer) is assigned formally known asa function owner. A typical ESW for an Anti-lock Braking System(ABS) ECU in automobiles mayhave a Controller Area Network(CAN) module interacting with a diagnostics module developedby another function owner. It is a challenge to test each functional unit of software moduleindependently before integration, on a physical hardware as the hardware needs a complete andmature software to run.

Third, even though rapid prototyping using MBD paves the way to run simulations of thedesign and verify the logical correctness at every stage, MBD does not solve the problem ofreal-time testing. The simulations of the ESW is not executed in the Real-time Systems (RTS)environment. The simulations of the ESW are run on a a different OS with its resources andscheduling algorithm.

Fourth, even though the emulation technology has been around several years, the empiricalevaluation of the platform is scarce. The tools used for the emulation are complex and poorlydocumented. In this case, a thorough exploration of the emulation tools is necessary.

Lastly, developing an emulation of real embedded hardware board is a development overhead.Analysis of the hardware, design of necessary specifications of the hardware to be implemented,the architecture of the Emulation SoftWare (EmSW) and customizing heavily coded emulationtools is time-consuming and performance-sensitive. Not only developing the EmSW is tedious,but there is also no standardized procedure or technique to test the developed emulation platform.It is, therefore, necessary to analyze the current test setups for RTS, emulation technology andtools offered, before considering the implementation of the EmSW.

Vanderlande baggage handling systems move 3.7 billion pieces of luggage around the worldper year, in other words, 10.1 million per day. In the controls of these systems, there is a shiftto decentralized control which leads to the increased complexity of embedded systems. These are



systems that consist of a mixture of mechanical and other physical components that are controlledby one or more hardware controllers (ECU). Vanderlande is looking for a method, based on virtualsystem integration, simulation and intelligent test generation, that addresses challenges specificallyraised when testing and validating this system-level behavior.

1.3 Research Questions

This section provides a list of Research Questions (RQ) that provide a guideline to carry out thisthesis work. The analysis of these research questions is utilized to identify the objectives andformalize a way to proceed further. The research questions are revisited in later chapters of thereport where they are answered based on the findings from the thesis.

RQ 1: What are the generic test and validation frameworks (in Vanderlande and overall) cur-rently available for EDLC? How extensively are the simulation and emulation techniques used inthe industry?

It is desirable to understand the current test environments across industries to gain an in-depthknowledge of the shortcomings of those systems. An embedded test environment can contain otherreal-time sub-systems such as PLCs interfacing with the HIL to test the ESW. The emulation ofthe complete test environment can be too far-fetched and time-consuming. The current hardwaredependency is mainly on the hardware controller(ECU) and hence it is chosen for the emulation.Additionally, by comprehending the shortcomings of the traditional test environments, it will beclear to distinguish between the scope of simulation-based testing and emulation-based testing.While simulation techniques such as MBD are also a type of virtualization, it is required tounderstand if the emulation out-performs in terms of creating an RTS test environment. Toachieve the speculated RTS environment a thorough study on the emulation techniques is requiredand the design of specifications for emulation must be concluded. Further, the literature studyfor the test environment at Vanderlande gives the necessary practical conditions to formulatethe design requirements. Once the design requirements are formulated a detailed study on theexisting tools and their compatibility with the design requirements to achieve the emulation canbe identified. Finally, it is necessary to familiarize with the usage of the emulation tool finalizedfor the implementation.

RQ 2: How can hardware emulation replace parts of the physical subsystems/components withinsimulated test setups?

This question explores the practical possibility of implementing and a test environment wherethe pure simulation of the real hardware is achieved. Emulation technology must be analyzed fora methodology to handle the scheduling techniques of the underlying OS. A hardware controllerconsists of processor, memory, I/O and peripherals interfacing and synchronizing based on theclock ticks generated by the hardware oscillator. The possibility of emulating these features ofreal hardware must be taken into account. Moving on, the emulation of all the components ofthe ECU is ambitious. The components of the hardware controller must be carefully analyzed toimplement a basic functioning real hardware platform and an easily testable peripheral to conductperformance tests. The emulated controller must be executed similarly to the simulated platformon a non-RTS with a traditional OS7 running underneath. The implementation strategy must becarefully analyzed, to determine, how and whether the emulated platform can be used instead ofa real hardware platform.

RQ 3: What are the specific methodologies to evaluate the performance of the hardware emula-tion?

The shortcomings of the current test setup analyzed in the first research question must be aperformance criterion for the measurement analysis of the emulated hardware. The methodology

7An OS that is used on desktop PC and is non real-time general purpose OS.



employed by the emulator to overcome the impact of the scheduler of the underlying OS and hard-ware platform is inspected. The performance is measured for practical purposes such as scalabilityof the emulated hardware, real-time behavior, functional/logical correctness and modularity testsfor the functions developed by the function owners. An approach to conduct these performancetests must be designed and measurement analysis must be carried out. The timing performance ishighly dependant on how the emulated clock is handled in the implementation. The performancetests must be executed to verify the timing differences between emulated clock and real-time clock.Detailed timing performance tests must be conducted to verify the effects of simulated time in theemulated hardware. Additional tests to confirm the reliability and availability properties of theemulated hardware must be carried out to analyze how close the emulated hardware can get tothe physical hardware.

1.4 Objectives and Goals

The complete thesis is divided into three main objectives mapped onto the research questions andthe nature of the thesis work carried out is in the same direction.

G1 Conduct a literature study analyzing the typical test environment for EDLC and identifythe need for emulation technology in EDLC. Based on this study, choose a suitable emulatorfor the implementation.

G2 Implementation of the hardware controller in the chosen emulator to realize a basic setup ofthe hardware controller which runs a dummy ESW.

G3 Perform the measurement analysis of the developed emulation model to determine the prac-tical usefulness of the emulated hardware.

The objectives G2 and G3 have secondary goals that add to the existing goals in the Section1.4.

Implementation Goals:

G2.1 Analyse the emulator tool chosen for the project and identify the emulation techniques imple-mented. Also, investigate already implemented hardware controllers for the implementation.

G2.2 Development of kernel image consisting of ESW and memory alignmnt and allocation, spe-cific to the selected hardware controller.

G2.3 Development of the processor, clock control, memory, I/O and GPIO for the hardwarecontroller.

Measurement Goals:

G3.1 Inspect the behavioral correctness of the emulated hardware along with running the de-veloped kernel image.

G3.2 Perform a thorough measurement analysis of the emulated hardware against real-time per-formance metrics such as timing and functional behavior.

G3.3 Perform tests such as scalability, reliability, and availability to satisfy the needs of embeddedtest setups in Vanderlande and overall.



1.5 Methodology

The project is defined keeping in the mind the current difficulties faced during the testing of ESW.The methodology involves literature study, investigating the options of virtualization to implementa virtualization technique. The methodology followed to realize the complete project is as shownin Figure 1.2.

Identify and formulatethe problem statement

Identify the researchquestions and goals

Evaluation of theresults

Propose a suitablesolution

Analyse thetechnology in the

company & acrossindustry

Implementation of theproposed solution

Merit the platforms anddeduce a platform for

implementation

Conduct a thoroughstudy of the chosen

platform

Figure 1.2: Methodology

1. Problem statement is formulated first to narrow down the scope of analysis and implement-ation.

2. Concrete research questions and goals are designed for step by step realization of the project.

3. A literature survey is conducted to have a broad idea of the test environments employed forembedded systems across the industry and at Vanderlande. The shortcomings of the testsetups for embedded systems are analyzed.

4. Suitable technology is chosen to instrument the solution. A thorough analysis of the selectedtool is made before implementation.

5. Implementation of the proposed solution.

6. Performance Evaluation of the implemented solution and analysis of its usefulness in thetest environment.

The methodology is re-iterated keeping in mind the complexity of the implementation. Evaluationof the results is also a stage that is re-iterative to analyze how the virtual platform fits into thecurrent need of the test setups for the embedded systems.

1.6 Contributions

All the goal listed in Section 1.4 were completed. Below are the contributions made during thecourse of this thesis.



• The emulator chosen in this project, QEMU, is widely used but is poorly documented. Adetailed and consolidated study of the emulator is provided in the Chapter 5.

• The hardware controller STM32F407ve is added to QEMU as a part of the hardware emu-lation development, with functioning clock and GPIO peripherals.

• Recommendations are made for the further development and use of the emulated hardwareand to construct a complete emulated test environment.

A complete list of the outcome of the thesis is listed in Chapter 7 answering the researchquestions formulated in Section 1.3.

1.7 Thesis Outline

This section provides an overview of the report structure and summary of each chapter. The goalsdesigned for this thesis are mapped to the chapters they are addressed in.

Chapter 1: Introduction

This chapter provides an initial introduction to the thesis, problem statement, methodology, re-search questions, goals and lists the contributions made to the topic.

Chapter 2: Project Context RQ.1, G.1

A literature survey of the verification techniques across industries is presented in this chapter. Thestudy correlates with the system under study and provides a brief overview of the requirementsthat have to be addressed for this project.

Chapter 3: Preliminaries RQ.1, G1

An overview of the virtualization technology, the reference model of the virtualization and vocab-ulary used in the emulation field is discussed in this chapter.

Chapter 4: Emulator Evaluation RQ.2 G2.1

Design requirements based on the literature study of the general verification techniques and EDLCat Vanderlande are generated to conclude on the hypervisor/emulator to be employed for thisproject. Various emulators are compared and the most suitable emulator is chosen based ondesign criterion.

Chapter 5: Implementation of the STM32F407 emulation RQ.2, G2.2, G2.3

This chapter presents the design and implementation of the emulation of STM32F407ve controllerhardware. The chapter also contributes towards creating a formal study of the emulator QEMUused to emulate the controller hardware.

Chapter 6: Performance Analysis and Evaluation of the Emulated Hardware RQ.3,G3.1,G3.2,G3.3

This chapter collects the metrics to measure the performance of the emulated hardware andpresent the results of the same. The chapter also throws light on the viability of the implementedemulation.

Chapter 7: Conclusions

A summary of the outcomes of the thesis and a layout for the future work is presented in thischapter.


Chapter 2

Project Context

This chapter provides an overview of the existing verification techniques followed by the variousembedded applications across industries. This discussion puts forth a detailed view of the typicalEDLC. Further, in the chapter, the test environment specific to the Vanderlande Industries isexamined to provide a correlation between the typical embedded EDLC structure and EDLC atVanderlande. This chapter benefits greatly to formulate the design requirements for emulation.

2.1 Literature Survey of the existing verification techniques

The drawbacks of the current verification techniques in embedded software development are twofolds. Firstly, the dependency of the software verification process on the hardware availabilityand secondly, the lack of real-time behavior of the techniques employed to eliminate the hardwaredependency.

Embedded systems across industries such as automotive, industrial process automation, health-care, and avionics are a conglomerate of extremely complex software application and mechanic-al/electrical sub-systems. The co-existence of hardware and software modules in embedded systemsis mirrored in test cycles of EDLC. Real-time SoftWare (RTSW) requires constant remodeling forvarious reasons, for instance, optimizations in architectural design, new customer requirementsor architecture design changes due to defects unseen during the verification process. The targethardware itself has a development life cycle: design, simulation, testing of hardware architecture,logic, circuit schematic and finally Printed Circuit Board (PCB) design [41]. This often leads tohardware unavailability at the early stage of EDLC and hinders the progress of the software testcycle. Figure 2.1 depicts a typical Real-Time System (RTS) with Real-time Computer System(RTCS) which is the computational system consisting of target hardware such as an ECU. TheRTSW and other software components if any, are a part of RTCS running on the target hardware.The controlling system or the target hardware controls the controlled system such as a plant modelvia sensors and actuators. The RTSW is the controlling ESW that conducts time-driven samplingvia sensors, makes a decision and informs the plant model in case of an event via actuators.


CHAPTER 2. PROJECT CONTEXT

Figure 2.1: Reference model for the RTS [14]

Due to the remodeling of the RTSW, the EDLC needs to be re-iterative which in turn makesthe complete process time-consuming. RTSW development is hardware dependant inherently dueto the correlation between the hardware and software and any delays in procuring the hardwareon the desk for developers to begin testing, can lead to further delays in the development cycle[41]. Once the target hardware is available for testing, setting up the test environment is alsotime-consuming due to the complex controlled system models. An interface between a controlledsystem and target hardware must be configured and tested as well. Target hardware such asan ECU hinders the testing of boundary conditions like high temperature due to the possibilityof damaging the hardware. A solution to overcome this hardware dependency and reduce thetime-to-market quotient is highly required for embedded system applications.

2.1.1 Conventional in-the-loop methods

To leverage the advantages of virtualization in a multi-domain system, there are several techniquesemployed in ESW testing. To compensate for the hardware unavailability in the early verificationphases of unit testing1 and integration testing2 , simulation-based testing is carried out. A simu-lation is an approximate imitation of the operation of a process or system. The act of simulatingfirst requires a model to be developed. This model is a well-defined mathematical description ofthe simulated subject and represents its key characteristics, such as its behavior, functions andabstract or physical properties. The model represents the system itself, whereas the simulationrepresents its operation over time [38]. The cause for the hardware dependency and the currentsolution employed to eliminate the dependency is presented in this section. Figure 2.2 depicts theEDLC typically followed in embedded software development. The EDLC is highlighted with thephases that are majorly affected due to the hardware dependency and simulation techniques usedin every phase.

1Unit testing is a level of software testing where individual units/ components of a software are tested. Thepurpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part ofany software.

2Integration testing is a level of software testing where individual units are combined and tested as a group.The purpose of this level of testing is to expose faults in the interaction between integrated units.



Requirements

System Design

ArchitecturalDesign

ComponentDesign

Code /Implementation

Unit test

Integration test

System test

Operation /Acceptance test

MIL

SIL PIL

HIL

HIL

Figure 2.2: EDLC with problem area highlighted and simulation techniques used at specific phases.

Simulation-based testing is agile and adaptable to every stage of the EDLC. The goal ofthe simulation is to front-load the testing process by enabling software teams to create and runtheir software tests before the actual ECU hardware is available. There are several simulationstrategies used that are suitable to each phase of EDLC which can be referred to as XIL [16].Figure 2.3 defines the ”X”, with X representing any control Model (M), software (S), Processor(P) or Hardware (H) under test. The simulation requirements vary depending on the phase ofEDLC. In XIL simulations, the ”X” always interacts with a plant model which is the controlledsystem as shown in Figure 2.1.

Figure 2.3: Various simulation types used in ESW testing

In Model-In-the-Loop (MIL) simulation, the controlling system (controller) model is simulatedon the host PC together with the plant model (including mechanical, electrical, thermal, etc.,effects) or stimulus signals. The MIL simulation verifies the algorithm design and provides areference for the next steps. In MIL tests, the model is under test. The goal is to verify the modelcorrectness with respect to the control algorithm or a reference model [17].

In Software-In-the-Loop (SIL) simulation, the generated C code of the controller model iscompiled and simulated again on the host PC. In SIL tests, the main tests are run to validate thegenerated code or controlling software(RTSW). The Controlling software interacts with the plant



model or the stimulus which is the controlled system. The C code is simulated together with thesame plant model used in the MIL phase. Typically, code coverage at the unit testing level ismeasured in this phase. The problem with SIL is that the C code is compiled for the host PCinstead of the target hardware. This may introduce differences in precision due to different datatypes (saturation and overflow effects), as well as other problems due to resource limitations onthe target hardware (memory and processing power) [45].

Processor-In-the-Loop (PIL), is used to overcome the limitations of SIL. PIL still focuses onthe control algorithmic implementation, but this time the C code is compiled for the targetedprocessor architecture. PIL simulation is carried out to test the reference model shown in Figure2.3. PIL level of testing can reveal faults that are caused by the target compiler or by the processorarchitecture [36]. In PIL, the control algorithm is running on the target processor separately fromthe plant model. PIL simulation helps not only to identify any target related issues but also toprofiling code size, stack consumption and execution time of the generated code. PIL is rarelyused but sometimes used after SIL. However, HIL produces more detailed output than PIL andthe additional step of testing the control algorithm on PIL redundant.

Lastly, the HIL tests consist of the production/target hardware with all the I/O modules, peri-pherals and additional external hardware integrated. The target hardware with RTSW, interactswith the simulated plant model as intended in the final assembly.

However, HIL testing does not happen as a smooth continuation of the previous phases. BeforeHIL testing can start, the control function unit (software module) has to be integrated with manyother control function units, including many other different software layers such as OS, drivers, andmiddleware.3 The integration of these layers has been standardized by AUTOSAR and CMSISstandards. Even with such concrete standardization techniques, having the first instance of acompiled software stack is still a daunting task. The compiled software stack may not work evenafter compilation for the target hardware as it may involve modifications in the previous phasesleading to iterations of these phases. This task is performed by the software integration teamsbefore the ECU testing using HIL can start. Some of the previous tests created during the MILand SIL phases can still be applied here with/without modifications, but the big bulk of testcreation and execution can only happen at the end of the testing phase.

The conventional ESW verification process is time-consuming and tiresome due to the changeof the simulation methods at every phase with different XILs. It is quite often concluded thatkeeping these test systems consistent is a problem. In SIL and MIL, the hardware signals do notnecessarily guarantee to test functionality perfectly, leading to defects at the end [37]. Testingimplications can reach up to 40% of the development cost and effort and this situation can worsenwith defects at the end phases of EDLC. Whereas, using one test setup throughout the wholeEDLC cycle can ensure coherence and efficiency in the test cycle. The coherence of the test setupcan be achieved by the emulation technology by adding a virtual-Hardware-In-The-Loop (vHIL)replacing the XILs till system tests. With differing software compositions and logic, the vHIL testsetup remains constant and flexible while providing real hardware experience.

A methodology is required to test the component software from booting the firmware to runningthe application code. A simulation that provides near-native experience while maintaining thetiming performance of physical target hardware is desired. Uncovering the defects in early stageshelps to remodel, re-iterate easily and at a very immature stage of the ESW, proving to beinexpensive and less time-consuming. The technology offered by the emulation is discussed indetail in Chapter 3.

2.2 A study on current test environment

Vanderlande baggage handling systems move 3.7 billion pieces of luggage around the world peryear, in other words, 10.1 million per day. In the controls of these systems, there is a shift todecentralized control which leads to the increased complexity of embedded systems. These are

3Middleware is a set of software that executes between operating system and application to provide a unifiedinterface, scalable and transparent abilities for the application.



systems consisting of a mixture of mechanical and other physical components that are controlledby one or more hardware controllers (ECU). Vanderlande is looking for a method, based onvirtual system integration, simulation and intelligent test generation, that addresses the challengesspecifically raised when testing and validating this system-level behavior.

2.2.1 System Overview

This section provides an overview of the sorter systems developed at Vanderlande Industries. Thesorter systems consist of both hardware and software components interacting with each other. Theinspection of the current system aids in understanding the current limitations of the test setupemployed. The test setup at Vanderlande is practical model available to understand the hardware-software coexistence This study is extensively utilized instrument the design requirements for theemulation.

Hardware Overview

As the name suggests, the sorter system sorts parcels collected on the conveyor to their destin-ations. This section provides a brief overview of the sorter systems and their workflow as thetechnical context to the report.

The sorter systems are a complex set of machines which comprise of Programmable LogicController(PLC)4, vision systems, sensors, actuators, controlled high-speed conveyors and ECUs.The PLCs are the masters looking over the complete process and ECUs are the slaves receivingcommands from the PLCs to activate on an event. The ECUs are equipped with Ethernet tointeract with the PLCs. The conveyors have an entry point for parcels known as in-feed andexit point where they are sorted, known as out-feed. To push the parcels to their pre-defineddestinations or out-feeds, switches are placed. The ECUs are used to drive the switches thatfacilitate the sorting of the parcels by pushing them off the conveyors at specified stations. Theswitches are basically actuators. The decision of selecting the switch which sorts the parcel at itsdestination, at the exact time, when it is received on the conveyor is a control signal generated bythe ECU depending on the decision made by the RTSW. To arrive at the conclusion regarding theswitch that should be used to sort the parcel is taken by the ECU based on inputs provided by thesensors, PLCs and vision system that constantly track the parcels. Typically over 10,000 parcelsare sorted per hour, sorting more than 3 parcels per second. The conveyors run at high speedsand the ECUs sort at the appropriate destination, making the complete system deterministic5 innature.

ITEM 1 ITEM 1 ITEM 1

VISION SYSTEM

sECU2 Switch2

Sensor2

PLCProfinet

Ethernet

ITEM 1

sECU1 Switch1mECU

Conveyor

mECU -- masterECUsECU -- slaveECU

sECU3 Switch3 sECU4 Switch4

OUTFEED

INFE

ED

Sensor1

OUTFEED

Figure 2.4: Depiction of sorter system with ECUs, switches, parcel and conveyors

4A PLC is an industrial-grade digital computer designed to perform control functionsespecially for industrialapplications.

5A guarantee that when an action occurs, the time for the reaction has an defined upper bound



As depicted in Figure 2.4, when the item enters the sorter system, the bar-code, dimension ofthe parcel and orientation of the parcel is identified by the Vision System. The bar-code containsthe information about the destination of the parcel determining at which particular out-feed theitem must exit to get sorted. This information is conveyed to the PLC via Ethernet communication.The conveyor speeds are controlled by the PLC by reading the sensors communicating over theProfinet protocol. In essence, the PLC is the master of the complete system. To sort a parcel,two switch frames are required and each switch frame is controlled by one sECU. Another ECUdepicted as mECU in Figure 2.4 is the master ECU that communicates with the PLC to receivethe information provided by the vision system. The mECU is dedicated to pre-assign the sECUsto drive the switches controlled by them to sort the parcel to a specific out-feed. The destinationand out-feed are mapped to each other to sort the parcels. The sECU1 and sECU2 are selectedbased on the destination/out-feed the parcel belongs to as shown in Figure 2.4. In this completesetup, two different control algorithm or the RTSW are flashed onto the mECU, sECU1, sECU2,sECU3, and sECU4 that control one master ECU and four slave ECUs. An ESW developer ofthe RTSW requires at least one ECU to test both the application code(RTSW) separately andalso needs a virtual system that simulates the environment parameters. The environment contexthere is the plant model, that contains the PLCs, sensors and vision system which provide inputsignals to the ECUs and hence need to be simulated to test RTSW in real-time. The switches andactuators are another hardware interface external to the plant model.

The hardware study brings out the scalability factor into account. It can be observed fromFigure 2.4 that each switch has two sECU and another dedicated mECU to monitor the twosECU. Conveyors at parcel sorting systems can be pretty long consisting of multiple out-feedsand multiple switch frames. With the increasing number of switch frames, the number of ECUsincreases three folds, making scalability an important performance metric for the virtualization.

Software Overview

The software overview is one of the important factors for this project. The RTSW should notrequire any changes in order to test it on the emulation platform. Any additional interface addedto RTSW to run/test it on the emulation platform, may introduce new errors. It is also anoverhead for the developers during the implementation of the RTSW and after the testing of theRTSW as the interface must be excluded for the final production. The RTSW must be compatiblewith the new virtualized platform and hence understanding RTSW structure is a requirement forthis project.

Current plant model and HIL based testing

The plant model as discussed in the previous chapters is a mathematical model of the sub-systemsto generate environmental inputs to the target hardware. All the elements of the sorter systemsexternal to the target hardware are incorporated into the plant model except the switches andthe actuators. The switches and actuators are physically connected to the target hardware. Theplant model is the controlled system of the RTS as shown in Figure 2.5(a). The controlling systemmECU/sECU interacts with the plant model via actuators. The controlling software RTSW isexecuted on the controlling system. The plant model in this context is the model of PLCs, thattracks parcels based on the signals received by the sensors. The plant model also incorporates thesimulation of parcels and the configuration of the switches. The vision system that also contributesto the tracking of the parcel runs as an independent program to track the parcels simulated byplant model. The simulation of the plant model is carried out on a desktop PC in MATLAB-Simulink software and a special hardware called Speedgoat is utilized to run the plant model asshown in Figure 2.5(b). Automotive industries, for example, simulate acceleration signals, roadconditions, crash signals etc and feed those signals to the target hardware to analyze the real-timeresponse of the RTSW. A similar setup is used at Vanderlande to simulate the plant conditionsby the Speedgoat. A Speedgoat is a heavy-duty PC that runs the Simulink model of the plantenvironmental inputs. It is largely used to test embedded controllers without having to test them



in a real plant setup.The Speedgoat does not randomly generate the ”items” or parcels that should be sorted by

the controller. The number of items, their length, and type are pre-selected by the tester in theMATLAB GUI for Speedgoat. These items need to be communicated to the vision system as PLCwould normally communicate with the vision system in real-time. Figure 2.5(a) and 2.5(b) showthe detailed depiction of the Simulink plant model and the complete HIL system. The plant modelkeeps track of which switch will be selected for the item sorting for its own algorithm so that itcan generate sensor signals for the controller.

Configuration

Tracking

Switch Positions

Parcels

Sensors

Signalgeneration

Data LoggingSIMULINK PLANT MODEL

(b)

CONTROLLING SOFTWARE (RTSW)

CONTROLLING SYSTEM(ECU)

SWITCHES /ACTUATORS

SPEEDGOAT

Inputs

Data Log

RTSRTCS

CONTROLLEDSYSTEM

ControllerOutput

SIMULINK PLANTMODEL

DEVELOPMENT PC

(a)

ControllerOutput

Figure 2.5: plant model as a sub-system in complete test setup (a) Sub-systems of plant model (b)

The HIL synchronizes with the Speedgoat for receiving and transmitting the sensor signals. TheSpeedgoat can synchronize with an external device with a clock for timing by specific I/O modules.For example, a camera with a clock can synchronize by the IO811 Camera Link I/O module bycapturing the simulated timing signal of the Speedgoat. The complete model is run based onthe clock signal and synchronized. Alternatively, Speedgoat can synchronize on an external clocksignal where two different sub-systems can synchronize on the clock pulse. Synchronization onPulse Width Modulation (PWM) signals can be realized by a PWM Capture Code Module runningon a Simulink programmable FPGA.

Embedded Software architecture

The embedded controllers mECU/sECU used for the sorting systems are the STM32F407ve hard-ware boards from STMicroelectronics. STM32F407 is a powerful controller with a Cortex-M4processor, I/O, and peripherals. The detailed discussion on the STM32 is done in chapter 5. TheESW architecture choices are made carefully keeping in mind even the PCB design concerningthe choice of peripherals. The interrupts and also choice of libraries are noted while designing theESW architecture. Figure 2.6 and Figure 2.7 show the ESW architecture.

The ESW has a customized Scheduler running above the hardware, developed in-house byVanderlande. Due to the bare-metal structure of the software architecture, there are internallydeveloped libraries which support functionalities of an operating system such as scheduling.6

6Scheduling is a method that is used to distribute valuable computing resources, usually processor time, band-width and memory, to the various processes, threads, data flows and applications that need them. Scheduling isdone to balance the load on the system and ensure equal distribution of resources and give some prioritizationaccording to set rules.



Figure 2.6: General Embedded Software Architec-ture of STM32 [19]

MCU (Physical hardware)

HAL

CMSIS

Custom Scheduler MiddlewareComponents

Embedded Software

Figure 2.7: HAL layer in the ESW

The functionalities facilitated by the Scheduler are discussed in Section 5.2. The CMSISlibrary as shown in Figure 2.6 supports the interface between the hardware and the software. TheCMSIS library is created by ARM and used by STMicroelectronics making the application codeportable on different STM controllers. The CMSIS library converts the machine level languageinto readable code, which is easy to understand and maintain. The Hardware Abstraction Layer(HAL) [51] driver as depicted in Figure 2.7 wraps around the CMSIS library and provides a genericmulti-instance simple set of Application Programming Interfaces (APIs) to interact with the upperlayer (application, libraries, and stacks). In addition to the CMSIS library, the ESW is embeddedwith Ethernet, Profinet and a custom library for the functioning of the ESW on the bare-metalcontroller. The time is supplied by the SysTick of 1ms each tick. This is used by TIMER functionsfor various timing requirements. The ESW is compiled and used on the windows environment. Theskeleton code for the developer is created by the STMCubeMX application, which adds the HALdrivers as well. Other peripherals of choice, and their initialization, and configuration are selectedin the STMCubeMx application to generate the skeleton code. The STMCubeMx applicationbinds all the libraries and ESW together to generate a binary file or a firmware. The binary fileis used to run on the STM controller along with motor support to run the switches for sortingthe parcels. It is very important that the application code is not altered for the emulation of theSTM32 and the requirement has been carefully taken into account during the implementation ofthe project.

The outcome of the literature study of the software overview of RTSW is that the RTSW has asimplistic lightweight scheduler with supporting libraries running below it. The RTSW is a fairlysimple program to control the switch frames, which allows developers to go bare-metal with asimple scheduler. From this study it can be concluded that, the scheduler is a part of firmwareand added as a library to the firmware. The emulation need not handle any heavy ISO kernelimage but simply add the lightweight scheduler as part of the firmware.

2.3 Lack of embedded environment in the simulation

While hardware unavailability is one of the problems faced during Unit testing and Integrationtesting, another important issue is defect snowballing due to hidden defects which do not surfacewithout physical target hardware. The application of ”in-the-loop” testing methods is chronolo-gical in the EDLC as shown in Figure 2.2. Even though the hardware dependency is eliminated inthe architectural and component design phases, the testing is still incomplete without the hard-ware. The testing on the production hardware is pushed to the end of EDLC. Unit testing and



Integration testing can still be performed by SIL but it is prominent that, at that point in EDLCverification must be carried out on physical target hardware.

With simulation, functionality test of the component developed can be verified but low-levelbugs related to firmware, defects that are CPU-architecture specific such as stack and memorycorruption defects or real-time timing irregularities cannot be examined. This is a result of thenon-real time environment of the simulation-based testing. In MIL and SIL simulation, the modeland software are compiled on the desktop Personal Computer(PC). A desktop PC is the traditionalnon-real time computer system, unlike the target hardware. A desktop PC does not have resourceconstraints like an RTS. By simulating MIL and SIL on a desktop PC, the defects that can beintroduced due to the specifications of the target hardware will be ignored. This, in turn, leads tosnowballing of the defects only to be detected at the HIL testing.

2.3.1 Difference between the resources of host PC and target hardware

In recent times, desktop computers have gained popularity due to high-end configurations. Forinstance, Intel’s i5 8th generation processor provides four cores for parallel computing capabilitiestypically with 16GB Random Access Memory(RAM) for industry purposes. The processors ofthese high-end computers follow x86-64 Instruction Set Architecture7 (ISA) and provide clockfrequencies 3.7 of GigaHertz (GHz). With this high computational power mostly for industrialpurposes, Windows OS is preferred. Heavy software such as MATLAB/Simulink, ASCET, andeclipse IDE can seamlessly run on the powerful computers. However, an RTS is highly constrainedin resources such as RAM and OS.

Real-Time Operating System(RTOS):

RTOS is a software component that rapidly switches between tasks, giving the impression thatmultiple programs are being executed at the same time on a single processing core[55]. In reality,the processor can only execute one program at any one time. The RTOS rapidly switches betweenindividual programming threads or tasks to give the impression that multiple tasks are executedsimultaneously. The difference between a General Purpose OS (GPOS) such as Windows or Linuxand an RTOS found in embedded systems, is the response time to external events. GPOS typicallyprovides a non-deterministic, soft real-time response, where there are no guarantees as to wheneach task will complete, but they try to stay responsive to the user. An RTOS differs in thatit typically provides a hard real-time response, providing a fast, highly deterministic reaction toexternal events[55].

Scheduling Algorithms: While switching between the tasks, the RTOS has to make a de-cision of choosing the most optimal task to schedule next. There are several scheduling algorithmsavailable, including Round Robin, Co-operative and Hybrid scheduling. However, to provide aresponsive system most RTOSs use a pre-emptive scheduling8 algorithm.

Tasks and Priorities: In a pre-emptive system, each task is given an individual priorityvalue. The faster the required response, the higher the priority level assigned. When working in apre-emptive mode, the task chosen to execute is the highest priority task that is able to execute.This results in a highly responsive system[55].

Processor Architecture:

Similar to the OS situation, the processors of the desktop PC and embedded devices are also notthe same. A central processing unit (CPU), also called a microprocessor, is the electronic circuitrywithin a computer that carries out the instructions of a computer program by performing the basicarithmetic, logic, controlling, and input/output (I/O) operations specified by the instructions.The desktop processors such as Intel’s cores are x86-64 architecture-based, which follow the CISCstandard and there is a range of processors for embedded devices with ARM architecture that follow

7The instruction set architecture serves as the interface between software and hardware.8In a pre-emptive scheduling tasks can be forcibly suspended. This is instigated by an interrupt on the CPU.



RISC standard architecture. The important differences between these two types of processors arethe ISA and cache memory architecture. The ARM Cortex-M4 with Floating Point Unit (FPU)is specifically designed for industrial applications.

The highlights being, the ARM ISA is designed such that, the instructions are known asmicro-codes which facilitate the execution of these micro-codes in one clock cycle. Whereas, theinstructions of x86-64 ISA are complex and need multiple clock cycles to execute which is notdesirable for RTS. Figure 2.8 provides a detailed overview of the RISC and CISC based ARM andX86-64 processor differences respectively.

Figure 2.8: Summary of ARM and x86-64 architecture [12] trends.

The cache accesses and optimizations made by both processors for instruction decoding asmentioned in Figure 2.8 also differ in ARM and x86-64 based processors changing the way theapplication code interacts with the embedded devices. The simulation fails to provide such contextto the RTSW under test. Specifically, Cortex-M processors employ a fault diagnosis strategy calledtrap errors that trap illegal memory accesses or attempts to execute non-existent instructions byfirmware. The fault diagnosis employed Cortex-M processors are listed below [39].

• Bus fault is an error that occurs during instruction fetch or data read/write.

• Memory Management Fault is a fault raised when attempting to execute an instruction froma non-executable area of memory

• Usage fault and Hardware fault are caused due to the undefined instructions and non-execution of appropriate fault handler for some reason respectively.

Since the simulation is running on the x86-64 processor and not on the intended target hardwareprocessor these faults remain hidden until the HIL testing.

Firmware:

A firmware is a software program or set of instructions programmed on a hardware device. Itprovides the necessary instructions for how the device communicates with the other computerhardware. A firmware usually consists of memory alignment information such as stack, heap,RAM, CCRAM, etc specific to the target hardware, Interrupt Vector Table(IVT) definition andprogram entry point for the processor. Any irregularities in the firmware can cause the system



to enter an Interrupt Service Routine9(ISR), Watchdog faults or segmentation faults, bootingerrors and memory misalignment. The firmware is not in the picture during simulation as simu-lation purely facilitates the test of controlling software and controlled system. There is no facilityprovided in the simulation setup to load firmware and test the RTSW.

The simulation also fails to provide real-time timing context to the complete testing method-ology. The time-sharing concept is discussed in the Chapter 3 along with the virtualization studyas both simulation and emulation employ simulated time to function. While simulation has beenwidely accepted and utilized across several industries extensively, the techniques fail to cater to theembedded systems testing to its low-level nature. The RTSW interacts with the low-levels of thesystem, very close to hardware levels and that needs to be incorporated in the testing of RTSW. Adetailed study in Chapter 3 on virtualization techniques show that these low-level functionalitiesof hardware is extended by emulation and reaches close to testing with target hardware.

2.4 Chapter Conclusion

This chapter introduces the typical verification techniques employed across embedded applicationindustries and at Vanderlande. This literature survey throws light on typical EDLC structure andits shortcomings. Later in the chapter, the inefficiencies of the typical verification techniquesare discussed which pave the way to determine the design requirements of the virtualizationtechnology.

9ISR is a software process invoked by an interrupt request from a hardware device. It handles the request andsends it to the CPU, interrupting the active process. When the ISR is complete, the process is resumed.


Chapter 3

Preliminaries

This chapter introduces the preliminaries or the context that has to set before diving into theimplementation of the hardware emulation. To begin the discussion, the drawbacks of the simu-lation are discussed in this chapter that motivates the idea of emulation of target hardware forthe EDLC. The emulation technology in detail is described and sets up the vocabularies of theemulation.

3.1 Virtualization Technology

Virtualization or emulation is the creation of software abstraction on top of a hardware platformand/or OS that presents one or more independent virtual OS environments [41] [48]. Such asoftware environment is called a Virtual Machine (VM). A hypervisor is a tool that facilitatesthe development of such a VM. Definitions of emulation and simulation can be easily confused.Simulation is a program that focuses on the behavior of the target hardware, has its own programto run and extract the key metrics like throughput, state, and utilization, etc. Subsystems andcomponents designed in simulations to specifications for one interface will not work with thosedesigned for another. For example, application programs, when distributed as compiled binaries,are tied to a specific ISA and depend on a specic operating system interface. This lack of interop-erability is confining [25] in embedded testing. Emulation technology, on the other hand, mimicsor replicates the target hardware by taking the hardware firmware and program the emulator toinvoke the firmware to further interpret same as a microprocessor. Emulation virtualizes a micro-processor, memory, I/O and also the interface to the underlying hardware. Emulation refers tothe ability of a computer program in an electronic device to emulate (or imitate) another programor device [11]. For example, if a non-HP printer emulates an HP printer, any software written fora real HP printer will also run in the non-HP printer emulation and produce equivalent printing.

Although, emulation in Embedded control systems is not as straight forward as the emulationin enterprise or personal computers. Embedded systems comprise of microprocessors, peripher-als, RTOS and specific purpose-built application [48]. The requirements for a embedded systememulation is discussed in Chapter 2.3.

3.1.1 Virtual machine reference model

To implement a VM, developers add a software layer to a real machine to support the inten-ded architecture. By doing so, a VM can circumvent real machine compatibility and hardwareresource constraints. A VM is a software abstraction layer between the physical hardware onwhich it is running and the firmware. A VM creates an illusion of a physical hardware for thefirmware/RTSW by mimicking the architecture and behavior of the physical subsystems of theparticular physical hardware. The VM runs on a hypervisor that facilitates the communicationbetween VM and the underlying hardware. Figure 3.1 shows the typical architecture of a virtual


CHAPTER 3. PRELIMINARIES

machine. Virtualization is paving its way into the embedded systems and has jargons that arecommonly used in virtualization technology. Below is the list of terms that are commonly used invirtualization[49].

HOST MACHINE

HOST OS (GPOS)

GUEST OS (RTOS)

VM1 VM2 VM3

HYPERVISOR(VMM)

DESKTOP PC

Figure 3.1: Typical architecture of a Virtual machine on host machine

• Host Machine: A host machine is the physical hardware such as a desktop PC. The hostmachine will consist of its own resources such as RAM, multi-core processors with x86-64architecture and I/O.

• Host OS: is the GPOS that runs on the host machine hardware. Typical GPOS in desktopPC is Windows/Linux.

• Guest Machine(VM): A guest machine is the VM that is emulated on the host machine.The guest machine has its own resources similar to the Host machine. It can act as anotherdesktop PC on the host machine that can load a GPOS other than the Host GPOS or can bea hardware board emulation with a processor, RAM, and I/O. For example, a Linux guestmachine can run on a Windows host machine or an Arduino board1 can be emulated on ahost machine. Even though the guest machine has its own emulated hardware, it is still justa program that is executed on the host machine.

• Guest OS: A guest OS is the OS that runs on the emulated guest machine. It can be bothGPOS or RTOS depending on the underlying guest machine.

• Bare machine or bare-metal System: A guest machine without an OS is a bare machine.Depending on the certain design requirements some RTS go for bare-metal development. Thereasons for having bare-metal systems is discussed in detail in Chapter 5

• Virtual Machine Monitor(VMM): is the hypervisor that presents an interface that lookslike physical hardware to the VM. The VMM facilitates communication between host OSand guest OS.

• Kernel image: can be a binary file, an elf file or an ISO file that provides a softwareabstraction to the underlying host hardware. A binary or elf file is usually used in bare-metal machine development and ISO file is used to run an RTOS/GPOS.

1Arduino is an open-source hardware and software company, project and user community that designs andmanufactures single-board microcontrollers and microcontroller kits for building digital devices and interactiveobjects that can sense and control both physically and digitally.



• Target: A target is a prefix used for any file, hardware, or terminology used concerning thephysical hardware that is intended to be emulated.

3.2 Rules for virtualization

A VM must possess the following characteristics to provide a robust framework and achieve anear-native performance when compared to the real hardware [26].

• Rule 1: Equivalence the VMM must provide an environment to the firmware/RTSW thatis essentially identical with the physical hardware.

• Rule 2: Efficiency the VMM should execute a large set of instructions at a time on thereal processor to achieve the near-native performance.

• Rule 3: Resource Control the VMM must be in complete control of system resources.Even though the OS underneath is pre-emptive, the VMM should gain back the control andcomplete the execution.

All three characteristics are important and contribute to making virtualization highly useful inpractice. The first (equivalence) ensures that the firmware that can run on the real hardware willrun on the virtual machine and vice versa. The second (efficiency) ensures that virtualization ispracticable from the performance point of view. The third (resource control) ensures that softwarecannot break out of the VM [49].

3.3 Types of virtualizations

A guest machine can be emulated in two ways: on the processor level or system level. Beforeunderstanding the types of virtualizations, it is important to understand the factor based onwhich the virtualization types are distinguished.

3.3.1 Privileged and non-privileged instructions

An operating system has dual-mode operations, user-mode and kernel-mode to ensure protectionand security of the system. The instructions that can run only in kernel-mode are called privilegedor control-sensitive instructions. The instructions that can run only in user mode are called non-privileged or behavior-sensitive instructions. In kernel-mode, the CPU has instructions to managememory and how it can be accessed. They also have the ability to access peripheral devices likedisks and network cards. The CPU can also switch itself from one running program to another. Inuser-mode, access to memory is limited to only some memory locations, and access to peripheraldevices is denied. The ability to keep or relinquish the CPU is removed, and the CPU can betaken away from a program at any time. When a privileged instruction is witnessed in the user-mode program, the user-mode program requests the OS to execute the instruction and switches tokernel-mode. After switching to the kernel-mode, the user-mode program has no control over theinstructions which will be performed in kernel-mode. This mechanism is the system call, which isimplemented in the CPU as the trap instruction. Once the OS traps the instruction, it performsthe following actions[53]:

• The user-mode program places values in registers or creates a stack frame with arguments,to indicate what specific service it requires from the operating system.

• The user-mode program then performs the trap instruction. Immediately, the CPU switchesto kernel-mode and jumps to instructions at a fixed location in memory.

• These instructions, which are part of the operating system, have memory protection so thatthey cannot be modified by user-mode programs, and may also be unreadable by user-modeprograms.



• The instructions, known as the trap or system call handler, read the details of the requestedservice and arguments and then perform this request in kernel mode.

• With the system call done, the operating system resets the mode to user-mode and returnsfrom the system call, or there is an instruction to do both at the same time.

From the point of view of the user-mode program, the trap instruction performs the instructionin a single instruction, with the results available at the next instruction. In reality, the CPU jumpsin kernel mode to the system call handler, which does the work and returns to the program in usermode. If any attempt is made to execute a privileged instruction in user Mode, then it will notbe executed and treated as an illegal instruction. The behavior-sensitive instructions can performactions such as reading processor states, system time and generate any trap instructions.

In a virtualization perspective, the control-sensitive instructions modify the privileged ma-chine state and therefore interfere with the hypervisors control over resources. While behavioral-sensitive instructions cannot change resource allocations, they reveal the state of real resources,specifically that it differs from the virtual resources, and therefore breaks the illusion provided byvirtualization. Together, control-sensitive and behavior-sensitive instructions are called sensitiveinstructions. Based on these two distinctions of instructions there are two types of virtualizationtechniques that cater to the specific requirements of System Under Test (SUT).

1. Process VMs: Process VMs enable running a target binary (e.g. Linux ELF file) ona host without emulating the guest OS. A guest binary can either run user-mode guestinstructions or perform system-calls to the host OS. The process VM maps guest system callsto host system-calls [15]. A process VM can either directly run user-mode non-privilegedinstructions or does a system-call to ask for some service from the OS. These process VMsshare a file system and other I/O resources of the host machine. The host machine allocatesreal memory and I/O resources to the guest processes and allows the processes to interactwith their resources [25].

As an example, a Process VM makes it possible to run a MIPS binary on an X86 machine. Itnot only gives a developer or user the flexibility to utilize the X86 host but also is economicalbecause more often than not special-purpose embedded systems are not available for everydeveloper.

2. System VMs: In contrast to the process VM, a system VM provides a complete, persistentsystem environment that supports an OS along with its many user processes. It provides theguest OS with access to virtual hardware resources, including networking, I/O, and perhapsa graphical user interface along with a processor and memory [25]. In system VM, instead ofmapping guest system-calls to host system-calls, a whole guest OS is emulated and a system-call in guest binary actually goes to emulated guest OS [15] that is, privileged instructionsare taken care by guest OS.

The hypervisor emulates the hardware ISA so that the guest application can potentiallyexecute a different ISA from the one implemented on the host machine. However, in manysystem VM applications, the primary goal is to provide virtualized hardware resources.

The equivalence and resource control properties of the virtualization are mainly satisfied by thesystem VM category of the virtualization. The efficiency in terms of execution speed is achievedby the process VM due to the partial functionality implementation. For this project, system VMis the kind of virtualization that should be chosen to achieve full system emulation.

3.4 Concept of Simulated time

Research on simulated time explains that ”simulations imply indexing of events based on somerepresentation of time”. In discrete-time simulation, time resolution may be expressed using afixed time step that separates consecutive event’s times [23]. There are two-time representations:



real-time (wall clock) and virtual clock. The time simulated by the virtual clock is known assimulated time or elapsed time.

The sample time can be represented in a simple time system that accommodates discrete-eventsimulation. The time system employs time points of the form [t, c], where t is simulated time andc is an integer counter. The event times of this form are compared lexicographically2 with the celements breaking the tie in cases where t elements are equal. In other words, c helps maintainan ordering of events within a single instant of simulated time [23]. The simulated time cannotsimply be the passage of time since the emulation starts. The virtual clock can be independent ofthe hardware clock on the host machine and generate its own simulated time which can be muchfaster compared to the hardware clock. However, in cases where the simulation has to interactwith the external interfaces, the virtual clock derives the time sense from the underlying hosthardware which introduces a dependency on the host machine for time-keeping.

3.4.1 Simulated time and OS

The simulated time starts when the emulation begins. The operating system employs two ways tomeasure the passage of time t, Tick counting, and tick-less timekeeping [54]. In Tick counting theOS sets up a hardware device to raise an interrupt periodically at a known rate, for instance, 1ms.After the requested elapsed time3 an interrupt is raised. The OS collects these interrupts (ticks)and keeps a count to determine how much time has passed. In tick-less timekeeping, a hardwaredevice keeps a count of the number of time units that have passed since the system booted, andthe operating system simply reads the counter when needed.

The GPOS usually use tick counting as the method of timekeeping and it is difficult to supportthis form of time measurement in emulations. As VMs work by timesharing with host physicalhardware, they cannot exactly duplicate the timing behavior of a physical machine. The VMsemulate the timer interrupts for tick counting but they usually get stalled due to the scheduleralgorithm employed by host OS and lack of CPU time when the host machine is busy. Thevirtual machine checks for pending virtual timer interrupts only at certain points, such as whenthe underlying hardware receives a physical timer interrupt for the VM or when the host machineis idle. In such cases, several interrupts are handled in a batch to catch up with the currenttime. For example, if 1s seems to have passed inside a VM, the time of a real clock may havegained 1.1s because the timer updates in the VM were delayed, or only 0.9s is elapsed, if the timerupdates were batched to catch up. The simulated time system fails to be deterministic due tothe dependency on the guest machine. Time, as measured by the guest OS, falls behind real-timeclock whenever there is a timer interrupt backlog in the VM. In perspective of the real-time wallclock, the VM may seem to run slow but when seen in the perspective of the VM, the simulatedtime is not relative to a real-time clock. It is absolute and creates an illusion of perfectly timedemulation.


It is understood in this chapter that virtualization technology is apt for embedded systems test-ing. The hypervisors / VMMs emulate hardware along with CPU architecture, memory and I/Oproviding a complete test setup to verify the RTSW from firmware boot to application function-ality. The drawbacks of simulations can be minimized by introducing virtualization-based testsetups in EDLC. Timing performance assurance is one of the major drawbacks of the emulationwhen used in a test setup with other sub-components functioning in real-time. The performancetest of the emulated hardware can reveal the timing inaccuracies of the hardware emulation.

2Lexicographic order is simply alphabetic ordering, generalized for non-letter values3Elapsed time is the wall time from the beginning to the end of collection


Chapter 4

Emulator Evaluation

This chapter presents an in-depth discussion about the emulation technology and currently usedemulators in various fields of embedded systems like the automotive industry and the industrialprocess automation domain. Emulation in test environments can be fruitful by replacing thedependent hardware. The test environment currently utilized at Vanderlande comprises of thedevices similar to the depiction in Figure 4.1. The figure contains a development computer tocontrol and program Speedgoat, a target computer (Speedgoat) and physical system such as anECU with actuators and switches.

Figure 4.1: General Test environment with Speedgoat [50]

The test environment at Vanderlande is consists of a Speedgoat that runs Simulink plant model,STM32F407 controller and controlled end devices actuators/switches. To realize the behind-the-desk testing, the STM32 controller with actuators/switches needs to be emulated and communicatewith the Simulink plant model directly. These sub-systems must synchronize on the simulatedtime and run on the development PC of a developer/tester. Currently, the scope of this project isto emulate the STM32 controller. An emulator selection is a vital decision for the implementationof the target hardware STM32F407. On achieving the emulation of the hardware as per the rulesof virtualization discussed in Chapter 3, a new EDLC model can be devised which would allowthe HIL testing in unit and integration test phases. Figure 4.2 depicts the EDLC model withemulated virtual Hardware (vHIL).


CHAPTER 4. EMULATOR EVALUATION

Requirements

System Design

ArchitecturalDesign

ComponentDesign

Code /Implementation

Unit test

Integration test

System test

Operation /Acceptance test

MIL

SIL vHIL

vHIL

HIL

Figure 4.2: Improvement in the EDLC after the introduction of virtual hardware in unit andintegration test phases.

4.1 Literature survey on emulators and emulator selection

This section discusses different emulators available that facilitate the virtualization of hardwareboards based on the requirements of the current HIL. To begin the implementation of the targethardware it is important to choose an emulator that caters to the design requirements of an RTS.In the next section, the design criteria for the implementation are discussed.

4.1.1 Design Requirements

The design requirements are the decisive criterion that must be taken care of to realize the emu-lation of the target hardware.

• The emulator can run on either Windows or Linux systems as the target hardware is astand-alone system.

• The emulator must be able to support bare-metal programming. The bare-metal OS isdiscussed in more detail in Chapter 5.

• The emulator must support full-system emulation (system VM) as discussed in Chapter 3.

• The Instruction Set Architecture (ISA) of the ARM processor must be supported or mustbe the same as ARM ISA. The guest OS uses the resources of the host OS and using thesame ISA increases the speed at which the instructions are executed in guest OS.

• The target hardware STM32F407 has Cortex-M4 processor and the emulator chosen mustprovide support to develop the Cortex-M4 processor.

• The emulator must possess the ability to emulate the peripherals and provide APIs to easethe co-design with the host OS.

• The target hardware in the current test setup interacts with other sub-systems of a largersystem. Similarly, the emulator must provide means to interface with other sub-systems likethe plant model in MATLAB and Ethernet communication with other ECU.

• For near-native experience, the emulator must employ certain optimization techniques tospeed up the execution of the emulated hardware.



Several emulators are open-source and are being extensively used by freelancers and hobbyiststo develop the target hardware boards of choice. Most of the emulators provide ARM ISA supportas ARM processors are one of the most popularly used processors in most of the hardware boards.

4.1.2 Emulator Evaluation

Emulator evaluation is part of the literature survey done to understand the emulator types andtheir specifications. The design requirements need to be satisfied by the emulator chosen todrive the implementation of the STM32F407 controller virtualization. The below section discussesdifferent emulators and their specifications. A collation of the emulator evaluation can be observedin Table 4.1.

Emulatorsand

properties

ARM Fastmodels

ImperasOVP

Silver QEMU

Support onWindows & Linux

Windows ++Linux + -

Windows + -Linux + -

Windows ++Linux - -

Windows + -Linux ++

Bare metalCoding

++ ++ - - ++

ARM ISAsupport

++ ++ - - ++

Cortex M4support

++ ++ - - ++

Ease of use + - + - - - ++External

Interfacing- - - - ++ + -

Near nativeperformance

+- + - ++ +-

Open SourceLicense

- - + - - - ++

Documentation + - + + + - + -

Table 4.1: A collation of emulator evaluation

• ARM fast models: Fixed Virtual platforms(FVPs) are fast models developed by ARMIP. These fast models are the emulations of Cortex-A, Cortex-R, Cortex-M processors. TheARM fast models also support bare metal programming [4]. These virtual models are avail-able in two forms: pre-configured fixed systems (with pre-defined cores, memory, and peri-pherals) called Fixed Virtual Platforms (FVPs); or with a tool-set to configure custom FastModel systems more representative of a particular hardware. The ARM support package inMATLAB integrates Arm Fast Models, both in a Fixed Virtual Platform and custom config-uration, with Embedded Coder from MathWorks. Users can generate code with EmbeddedCoder and run PIL simulations and Simulink External Mode tests on Arm virtual targets,just as they would with physical hardware [5]. While the ARM fast models are a perfect fitfor the project, there is no user documentation available to refer to. ARM and MATLABwork hand in hand as the development of the models needs a compiler and a developmentstudio which is provided by ARM. Both the software packages require licenses to use thecomplete setup, making it expensive to scale to all developers.

• Imperas -OVPsim and DEV: Open Virtual Platforms (OVP) is an open-source plat-form that facilitates virtualization of the hardware boards. OVP provides OVP models,Instruction Set Simulators (ISS) and modeling APIs. OVP models are the executable codesof processors compatible for both Windows and Linux systems [40]. The models can be



downloaded either as source files or executable codes which is an advantage over ARM fastmodels, as FVPs can only be run as executable in MATLAB and leaves no room for cus-tomization. Currently, in OVP there are processor models of ARC, ARM, MIPS, PowerPC,Renesas, Altera, Xilinx, and OpenRisc families. OVP also provides a simulator to run theOVP models and is freely available. The APIs provided are mainly developed in C, C++and System C [49].

• Silver by Qtronics: Silver, Virtual integration platform developed by Qtronics is based onSIL simulations for Windows PC. Silver can integrate multiple compiled modules mimickinga virtual controller and plant model components. Controller code can be imported fromSimulink, Embedded Coder, TargetLink, Ascet or hand-coded C [35]. The code is importedinto the Silver application as an executable known as modules and integrated with othermodules to share data during their execution. Silver provides a rich set of widgets used toconfigure, save and load a graphical experiment environment for a set of modules [28]. Silverprovides APIs and internal support, especially for automotive standards. The application istailored to support the automotive controller software including the widgets. The softwareneeds to be licensed from Qtronics making it expensive to scale.

• QEMU: QEMU is Quick Emulator, open-source software that supports virtualization ofhardware boards with support of various CPUs such as x86, PowerPC, ARM and Sparcon several hosts x86, PowerPC, ARM, Sparc, Alpha, and MIPS [9]. It especially has goodsupport for ARM guests. QEMU supports full-system mode emulation that is, emulatingperipherals, memory and I/O along with processors. QEMU is supported on both Linuxand Windows PC, downloadable both as binary files or source code and executable. QEMUalready has various hardware boards emulated such as Raspberry Pi, TI Stellaris, versatilePB and many more. The internal APIs provided by QEMU increase the usability of thesoftware. Cross-platform virtualization can be achieved by running ISO of an OS on anotherOS, but QEMU also supports bare-metal programming.

4.1.3 Motivation for QEMU

The emulator chosen for this project is Quick EMUlator, first developed by Fabrice Bellard licensedunder GNU General Public License (GPL). QEMU is a hypervisor that supports virtualizationin two modes; system-mode and user-mode. User-mode emulation allows a process built for oneCPU to be executed on another. This is achieved by a feature, Dynamic Translation of theinstructions for the host CPU and converting Linux system calls. While used with the same guestCPU as host CPU, QEMU claims to provide near-native performance with the accelerator [27].System-mode emulation as discussed before is full-system-mode emulation. QEMU provides near-native performance due to the optimizations used by the software. QEMU fetches the instructionsfrom guest machine / OS and translates them into host-specific or host compatible instructions.This translation is done by a feature known as Dynamic Translator. The dynamic translatortranslates the instructions into pre-compiled C functions known as micro-operations. QEMU isfaster compared to other emulators due to the optimizations implemented for quick executions ofthe target instructions by micro-operations. QEMU caches the micro-operations to eliminate thetranslator overhead and stores frequently used instructions in a buffer for later use. Since QEMUis quite large in the codebase, debugger support is provided. QEMU supports GNU Debugger(GDB) for debugging. The GDB is a portable debugger that runs on many Unix-like systemsand works for many programming languages, including Ada, C, C++, Objective-C, Free Pascal,Fortran, Go and partially others.

Apart from the technical aspect, QEMU is widely used by industries and universities foremulation. One such work is carried out by students of LUND university to implement a cameraplatform in QEMU [49]. A considerable amount of reference work is available to refer to andunderstand the complex structure of QEMU. The internal APIs are very useful as they are heavilyused in the source code. The source code is built-in C but very poorly documented, introducingdifficulty in understanding the basic concepts and APIs of QEMU. But since extensively used by



freelancers, there is information on the usage of the APIs. All custom machines developed areavailable on GitHub public repository and are free to use for further development. QEMU alsoprovides a wiki page and a mailing list to refer to and to post any queries.

ARM FVP is not free, hence it is very expensive to scale. It also has no documentation oras popular as QEMU to refer to an online community. The FVPs by ARM can only be used asexecutable in MATLAB, which poses difficulty in customization. Also, there is no documenta-tion available to work with these models and are rarely used in industry or universities. OVPperformance is quite low when compared to the free versions and licensed versions making it lessinteresting for this project [49]. It is also not as widely used as QEMU. Silver by Qtronics iscomplex to customize as the internal APIs by default support the virtualization of automotiveapplications [35]. To further implement behind the desk testing and virtualizing the complete testenvironment, QEMU is also given as a support package in MATLAB which may help in interfacingwith Speedgoat for the plant model. Keeping in mind these factors, QEMU is chosen to implementthe emulation of the STM32F407 target hardware for this project.


To achieve the virtualization of the target hardware in the test environment, emulation technologyis suggested. This chapter throws light on the emulation technology and range of emulatorsavailable for the virtualization. Four emulators are analyzed and compared to continue withthis project. Keeping in mind the design requirements that must be satisfied to carry out theemulation of hardware board STM32F407 and also the flexibility and features provided by thefour applications, QEMU is chosen.


Chapter 5

Implementation of theSTM32F407 Emulation

This chapter documents the implementation of STM32F407 hardware emulation. As illustrated inFigure 5.1, the emulation of an ECU is far-reaching with respect to the complex sub-modules theECU comprises. The vital modules that are necessary to realize a basic functioning STM32F407controller are investigated in this chapter. The variant of STM32F407 emulated in this project isthe STM32F407VETx [52], which contains the Cortex-M4 processor with FPU core and peripheralsas shown in Figure 5.1.

Figure 5.1: System architecture for STM32F407xx devices [52]

The mECU and sECUs depicted in Figure 2.4 are STM32F407 ECUs by STMicroelectronics.The STM32F407 controllers in the sorter system are incorporated with two motors to run theswitch frames so that the parcels can be moved towards the out-feed. Although most of the peri-pherals of mECU and sECU are utilized in the sorter systems such as CAN, TIMERS, UART,General Purpose Input/Output (GPIO), and Ethernet [52], only selective peripherals are chosento begin the emulation with. A steady clock (or timer) tick is essential to synchronize user inputs,scheduling, and other basic timing tasks of guest machine. The STM32 physical hardware has aninternal oscillator clock that generates the system clock (SYSCLK). The GPIO peripheral is usedfor I/O transactions with the external hardware such as an actuator. GPIO can also be compar-atively straightforward to develop and test emulation. Finally, the controller communicates with


CHAPTER 5. IMPLEMENTATION OF THE STM32F407 EMULATION

other sub-systems to synchronize in the sorter system via the Ethernet module. Considering thecomplexity of developing the stack, MAC layer, buffer module and 57 registers for Ethernet emula-tion, only the clock control, processor, and GPIO are considered for emulation in this project. Thecomplete Ethernet specification can be referred from the reference manual of the controller [52].The ARM Cortex-M4 processor is already emulated in QEMU with TI Stellaris board peripher-als, memory, and I/O. The ARM Cortex-M4 processor emulation can be used for STM32F407controller peripherals, memory and I/O instead. The setup required to achieve emulation, thebackground study, and QEMU workflow is discussed further in this chapter.

5.1 Emulation Setup

QEMU can be downloaded for both Windows[43] and Linux[42] platforms. It can be downloadedas an executable and run as an application file. QEMU as an executable file only allows usingthe application by running the emulated hardware with or without the OS. This option is viablewhen the hardware is already emulated and can be used directly. QEMU also allows to use it asa virtual platform to run a different OS. For example, Linux can be used on a Windows OS as astandard PC. For this project, it is necessary to have the source code of QEMU to add a custommachine. The source code files can be downloaded from GitHub. QEMU is largely dependent onlibraries libffi, libcnv, gettext, glib, libsdl, pixman, and zlib. All these libraries must be installedpreviously along with the GCC compiler. Apart from this heavy library dependency, QEMU ispoorly documented. Due to contradicting instructions on how to configure QEMU on Windows,it is difficult to compile the source code and to use the Windows environment for custom machinedevelopment. This step is an overhead when compared to development on Linux, which is muchmore compatible with QEMU. Additionally, QEMU’s main host platform is Linux. Consideringthese factors Linux is chosen as the host machine for the ease of development.

5.1.1 Development Environment

Most Linux platforms come with the library packages listed in Section 5.1. Additional libraries canbe installed through a terminal and simple commands listed in QEMU official website to compileQEMU. Linux also comes with the GCC compiler and make packages. On Windows, however, allthe packages must be installed separately along with the MYSYS (minimal system) a componentof MINGW (Minimalist GNU for Windows) which provides a Unix-like shell environment.

GCC compilers need an additional ARM toolchain to compile for the target architecture.In particular, the EABI toolchain is required for embedded applications. A software tool-chain isrequired to compile source code into binary machine code and to link the assembly code with objectcode. In this case, the target processor is the ARM Cortex-M4, which is based on the ARMv7architecture and the Linux machine is an x86-64 architecture and hence cross compiler is used.The cross compiler used is the arm-none-eabi-gcc[20] compiler. Unix cross compilers are looselynamed using a convention of the form arch[-vendor][-os]-abi. In this instance, the architecture isARM and vendor who is the toolchain supplier, target OS and abi stands for Application BinaryInterface. In the case of the arm-none-eabi toolchain, the architecture is ARM, with no vendorand embedded abi without any OS. This indicates that the application logic is bare metal withoutany OS. More about bare metal system is discussed in Section 5.2

QEMU’s source code is complex. The code structure and file structure is needed to be analyzedto understand how the program is built to add a new custom machine. The code structure isstudied in Eclipse development studio initially but Vim is used to develop and code the emulation.Eclipse DS-5 Workspace development Studio for C/C++ gives an easy link between the functionsused and their definitions. Vim is an open-source text editor that provides a command-lineinterface to traverse through files and folders, to edit the text and also compile instantly. Boththe tools are used in parts as per requirement.

Once the basic emulation setup is done, QEMU can be downloaded from the GitHub officialmirror repository. After the repository is downloaded, QEMU files must be configured with a



target list. The repository consists of source code for all the architectures and associated hardwareboards previously emulated. To make the QEMU light, only the target architecture required canbe configured using the argument target-list=arm-softmmu. This target list alone supportsnearly fifty different hardware boards emulation. QEMU has good support for specifically ARMguest architectures as the ARM architecture is widely used across industries. The list of machinessupported can be seen by running the command qemu-system-arm -machine help. Once theSTM32F407 machine is emulated it should be added to the list of the machines displayed inAppendix Listing A.

5.2 Bare-metal Development

Bare-metal programs run without an OS beneath. The RTOS provides multiple functionalitiessuch as scheduling & multi-tasking, ensuring smooth program flow. However, with hard real-timeconstraints, RTOS can be an overhead. Several factors lead to choosing bare-metal programmingover RTOS. The ESW at Vanderlande is run with an in-house scheduler or similar to the FreeRTOS[10]. FreeRTOS is further optimized compared to an RTOS that is specifically used for schedulingand inter-process communications.

• Sequential Execution : Concurrency is one of the major factors that need to be satisfiedby an OS to achieve maximum throughput. The tasks in the ESW for sorter systems aresequential, executing one after the other in the main loop which eliminates the requirement ofmulti-tasking facilitated by an OS. The one-directional flow of tasks can be witnessed whena parcel arrives to be sorted, an mECU is informed about the arrival of the parcel, mECUpre-selects the switches that need to be activated to sort the parcel. sECU1 and sECU2 sortthe parcels by running switches as per requested one after the other. It is such that, evensECU1 and sECU2 are unaware of each other’s existence. The tasks can be pre-emptive dueto interrupts defined in the system which is handled by the scheduler in place.

• Memory footprint: Memory footprint can be one of the factors that can be consideredfor choosing an OS or going bare-metal. The RAM size provided by STM32F407 is 128kBand flash memory of 1MB making the memory factor, not a critical aspect to decide on.Although in embedded controllers with lower RAM and flash size, the memory footprintfactor must be considered as RTOS consumes up to 6-8kB of flash size[10].

• Light-Weight(LW) Scheduler: LW scheduler such as popular OS FreeRTOS is light-weight and does not include a fully functioning RTOS. Schedulers such as provided byFreeRTOS are ideally suited for deeply embedded applications having both hard & soft real-time applications[7]. The scheduler used in sorter systems is also LW catering only necessaryfeatures of an RTOS. It provides minimum core features of RTOS scheduling, inter-taskcommunications, timing, and synchronization primitives only. Any added functionalities arecustomized as per the application needs.

• Idle time Processing: The ECUs operating in the sorter systems are slaves receivinginstructions and input from PLCs(master) and other sub-systems like the vision system.The ECUs are driven by events and tasks and can be a-periodic and sporadic where theECU need not measure a parameter continuously. Due to this slave characterization ofthe ECUs, there is a substantial amount of idle time processing unlike other continuouslyprocessing ECUs in automotive industries. An ABS ECU in an automobile must measure theacceleration periodically, Whereas in the sorter systems, the main control system is handledby PLCs and not by the ECUs. For such conditions where idle time processing is involveda simple LW scheduler can be used instead of a fully functioning RTOS.

• Experience of Developers: One of the driving factors for choosing bare-metal devel-opment in sorter systems is the experience of developers working on low-level embeddedplatforms. The inexperience of developers with RTOS can lead to buggy software which is



hard to debug. Even though setting up an RTOS is simpler, debugging the misbehavingRTOS needs expertise. Having a customized scheduler facilitates control over the operations& timing parameter adjustments with task executions. Looking at the expertise in the teamwith embedded low-level programming, bare-metal programming is chosen as the way togo[10].

5.2.1 Binary File development

A binary file contains a startup code, linker script and application logic. The three files whencompiled together by the GCC compiler produce a binary file as shown in Figure 5.2. The applic-ation code is compiled with drivers and libraries to generate the object file. The binary file alsoincludes the scheduler code that is compiled with the application program.

Figure 5.2: Compiler stages to generate a binary file [20]

The startup code or also known as boot code must include the Interrupt Vector table descrip-tion, stack pointer and reset handler. A startup code also defines exception handlers with startaddresses. The memory alignment in Cortex-M4 is done in word(32bit) and the vector table in-terrupts are arranged accordingly with starting address from 0x0[52]. The ARM instruction setused is the Thumb instruction set, which has mostly 16 bit long (half word-aligned) instructionsand some 32-bit long instructions[3]. The instruction set format can be chosen by the developerto be ARM or Thumb but only one format can be active at a time.

12 . s e c t i o n . t ex t . Reset Handler3 . weak Reset Handler4 . type Reset Handler , %func t i on5 Reset Handler :6 l d r sp , = e s t a c k /∗ s e t s tack po in t e r ∗/78 /∗ Copy the data segment i n i t i a l i z e r s from f l a s h to SRAM ∗/9 movs r1 , #0

1011 /∗ Zero f i l l the bss segment . ∗/12 F i l l Z e r o b s s :13 movs r3 , #014 s t r r3 , [ r2 ] , #41516 LoopFi l lZe robs s :17 l d r r3 , = e b s s18 cmp r2 , r319 bcc F i l l Z e r o b s s



2021 /∗ Cal l the a p p l i c a t i o n ’ s entry po int . ∗/22 b l main23 bx l r24 . s i z e Reset Handler , .−Reset Handler

Listing 5.1: Startup code with definition of the Reset handler and global data initialization

Simple startup code is written during implementation but it failed to boot the processor andhence a proprietary startup code is used generated by the STM32CubeMx application as shownin Listing 5.1. The startup code needs to initialize the stack and global data memory which wasmissing in the simple startup code. The initialization is handled in the Reset Handler which isdefined as an entry point for the processor when it is powered on. The rest of the vector tableis defined as per the STM32 vector table[52]. The handlers or exceptions are defined as WEAK,which defines that the handlers can be defined anywhere else in the program.

The linker program is the .ld script that links the application code with the startup code. Theprocessor must jump from initialization to the application code which is linked by the linker script.Both the startup code and application code are converted to object files and are linked togetherby the linker script.

1 ENTRY( Reset Handler )23 /∗ Highest address o f the user mode stack ∗/4 e s t a c k = 0x20020000 ; /∗ end o f RAM ∗/5 /∗ Generate a l i n k e r r o r i f heap and stack don ’ t f i t i n to RAM ∗/6 Min Heap Size = 0x200 ; /∗ r equ i r ed amount o f heap ∗/7 Min Stack S i ze = 0x400 ; /∗ r equ i r ed amount o f s tack ∗/89 /∗ Spec i f y the memory areas ∗/

10 MEMORY11 {12 RAM ( xrw ) : ORIGIN = 0x20000000 , LENGTH = 128K13 CCMRAM (rw) : ORIGIN = 0x10000000 , LENGTH = 64K14 FLASH ( rx ) : ORIGIN = 0x8000000 , LENGTH = 512K15 }1617 /∗ Def ine output s e c t i o n s ∗/18 SECTIONS19 {20 /∗ The star tup code goes f i r s t i n to FLASH ∗/21 . i s r v e c t o r :22 {23 . = ALIGN(4) ;24 KEEP( ∗ ( . i s r v e c t o r ) ) /∗ Startup code ∗/25 . = ALIGN(4) ;26 } >FLASH

Listing 5.2: Snippet of the linker code

The linker script defines the memory layout of the System-On-Chip(SOC) with memory areaslike RAM, CCMRAM, and flash with allocated memory space[52]. The estack used in the startupscript in Listing 5.1, is defined in the linker script as shown in Listing 5.2 line 4, with the stack’saddress. The vector table is placed in flash memory at the starting address 0x0. The definitionof the memory layout and code placement can be confirmed with GNU bin-utilities commandreadelf -an elf filename.elf. The command displays the memory allocation and vector tableplacement in the memory layout of the generated elf. It can be seen in Figure A.1 and A.2 inAppendix, when readelf command is run with a stm32f407.elf file generated in STMcubeMx, itdisplays the memory layout with flash memory at 0x08000000 [52] and vector table starts at thesame address as defined.

Once the linker script is correctly defined, the .elf file can be generated using the commandarm-none-eabi-ld -T linker script.ld application code.o startup.o -o stm32f407.elf

A binary file can be generated by command



arm-none-eabi-objcopy -O binary stm32f407.elf stm32f407.bin[6].The object files of the startup file and application code are generated previously with -mcpu

parameter and argument as cortex-m4 which require the GCC binutilities arm-none-eabi-gcc

and arm-none-eabi-as. The developed binary or elf file is used as a kernel image which is passedas an argument to QEMU to load it while running the STM32F407ve machine. During furtherdevelopment and usage of the STM32F407ve machine in QEMU, the binary file is used instead ofthe elf file as a kernel image which is discussed further in Section 5.4.

5.3 QEMU detailed study

QEMU meets the rules of virtualization as discussed in Chapter 3, by putting in place optimizationtechniques which will be discussed in Section 5.3.1. To use the QEMU APIs and its debug features,it is necessary to understand the underlying QEMU functionalities. In this section, an overviewof QEMU optimization techniques, workflow and the essential APIs used are introduced.

5.3.1 Optimizations Techniques

This section provides an overview of QEMU optimizations techniques used to accelerate the emu-lation to achieve near-native performance. For QEMU, the emulated hardware is Target and thephysical machine whose resources such as memory, OS is being consumed on which the QEMU isrunning is called Host. In Host’s perspective, QEMU is a Guest running its own applications orfirmware. A bird’s eye view of the emulation setup is provided in Figure 5.3. QEMU implementstwo optimization techniques namely Binary Dynamic Translator(BDT) and Tiny Code Gener-ator(TCG) to accelerate the transaction between the emulated processor with ARM ISA and thereal processor with x86-64 ISA. The TCG is an intermediate phase of BDT optimization.

Figure 5.3: Depiction of Guest and Host machine view perspective

The BDT loads the binary provided through the command line and converts the instructionsfrom the binary on the guest machine to the host machine code. It is necessary to convert theguest code or target code into the host code to run the instructions on the Host hardware. Afterthe BDT loads the binary code, the TCG converts the binary code to host code as depicted in



Figure 5.4. The intermediate step of generating the OPcode1 for the x86-64 architecture is handledby TCG.

Figure 5.4: Working of Binary Dynamic Translator and Tiny Code Generator [44]

By employing BDT and TCG, more time is spent in executing the generated host code thangenerating the host code. The guest code is converted by fetching the Basic Blocks (BB). EachBB of instructions is known as Translation Block (TB). The guest code is first converted tointermediate code -TCG ops and then converted into the host code for the host’s architecture.When the guest code is converted from TBs, they are stored into a code-cache. This enablesfrequently used host code to be re-used without any lead time. QEMU utilizes another optimizationknown as chaining of TBs where the execution does not return to the static code (guest code)frequently. Once TB1 is executed, the control returns to static code and the next TB, TB2 getsgenerated. After TB2 is generated, it is chained to TB1. Due to the chaining of TBs, during thenext execution, when TB1 is executed TB2 follows it depending on the context in which TB1 wascalled.

5.3.2 QEMU workflow

A clear understanding of the QEMU code-base is a must to add new functionalities. The newlyadded emulated machine is run as a remote node with respect to the QEMU code-base[42]. TheQEMU code-base is well structured into specific folders with around 1300 files. The main file vl.cwhere the QEMU application is initiated is in the folder /qemu. Processor architectures such asAlpha, ARM, i386, MIPS are emulated and are present in the /qemu/hw directory. The processoras discussed in this project is the ARM Cortex-M4 and hence code for the STM32F407 should beplaced in the /hw/arm folder. The /arm directory consists of emulated hardware source codes.This folder also has a makefile.objs file that contains the list of source code file names that haveto be converted to architecture-specific object files using command obj-y. The ’y’ symbolizesto use the architecture CONFIG ARM V7M which is the default entry. Another option is tohave customized names with the preferred architecture which are added in the configure file indefault-configs/arm-softmmu.mak and used as obj-$(custom name).

QEMU can be called with the command from the Linux terminal as shown in Listing 5.3

1 qemu−system−arm −machine stm32f407ve scu −ke rne l stm32f407 . b inary

Listing 5.3: Command to invoke QEMU machine

The necessary QEMU code files that should be focused on are vl.c, cpus.c, cpu-exec.c, exec.c.The vl.c file is the main file where the code is initiated and the environment is set up. QEMU

1In computing, an opcode (abbreviated from operation code, also known as instruction syllable, instructionparcel or opstring) is the portion of a machine language instruction that specifies the operation to be performed.



first sets up an environment for the emulated machine with RAM size, the number of CPUs andkernel file[44]. The machine name and kernel file name are fetched from the user command lineinput. The RAM size, CPU name, and number of CPUs for the machine are defined in thestm32407ve scu machine description file. The description file is discussed in detail in Section5.4. The command-line parsing functions are achieved by QEMUOpts APIs which are defined byQEMU.

Figure 5.5: A depiction of QEMU code flow (Source: Stack Overflow, verified in GDB)

Once the basic environment is set up the execution branches to the cpus.c, cpu-exec.c & exec.c.A complete code flow can be seen in Figure 5.5.

The chosen CPU is passed to the cpu-exec function and the CPUState is checked that the VMor the CPU of the VM is not in stopped state. If the VM is not in stopped state, cpu can run()function is validated. Struct CPUState basically holds the state of the CPU with standard re-gisters, segments, FPU state & exception/interrupt handling [44]. Currently, QEMU cannot run



multiple CPUs in parallel. If more than one CPU is requested, the program round robins throughthe CPUs and runs them one after the other by cpu = CPU NEXT(cpu). The tcg cpu exec is themain function where the CPU execution begins. The CPU waits on conditions until the machineis kick-started. Once the machine start is received, the CPU is scheduled and resources are dedic-ated to the thread that is running the CPU by running the code as shown in Listing 5.4. QEMUemploys a global Mutex.

1 qemu mutex unlock iothread ( ) ;2 rep lay mutex lock ( ) ;3 qemu mutex lock iothread ( ) ;

Listing 5.4: Code to employ mutex on thread running the CPU to allocate resources to the dedicatedCPU

The structure TranslationBlock consists of Program Counter (PC) pointing at the current tband a flag to suggest in which context the code is generated. The TB that has to be translated issupplied by exec.c by finding the appropriate TB using tb find(). Figure 5.5 shows tb find fast andtb find slow functions to find the correct tb. In the current version of QEMU, the tb find fast andtb fine slow functions have been merged into tb find as it reduces multiple lock transitions betweenthe TBs in exec.c. The jmp functions define the offset in which the next TB is available, to providethe chaining of TBs optimization. The TB can be linked to another one by setting one of the jumptargets. Only two jumps are supported from one TB. TB traversals are protected by jmp lock.The destination TB of each outgoing jump is kept in jmp dest[] so that the appropriate jmp lockcan be acquired from any origin TB. This complete functionality is carried out in exec-all.h.

Virtual page mapping is also done in the exec stage where the memoryregion allocates thesystem memory, RAM and maps it to the physical memory of the real hardware. To generatethe host code, tb gen code() is called which places the generated code in to a memory sectionthat is locked by mmap lock() until the tb gen code() is executed. Once the execution completes,it is released with function mmap unlock(). The generated TB is added in the virtual PC hashtable for the fast lookup. The TCG comes into the picture when the application code has to betranslated. As shown in Figure 5.6.

Figure 5.6: A depiction of Binary Dynamic Translation [44]

The gen intermediate code() is called from the translate-all program to generate the interme-diate code. CPU env is passed as an argument to this function which provides the PC to the TBin a hash table which has to be converted to TCG ops. The disas functions short for disassemblein translator.c is the program where translation actually takes place. After the code is conver-ted to TCGops, tcg gen code found in tcg.c converts the TCGops to host architecture specific



code. The next TB is fetched and executed similarly as mentioned in above explanation by callingtcg qemu tb exec(env, tb ptr) from /exec-cpu.c. The tb ptr returns a long which is the next TBand tc ptr points to the generated host code, to which control is next transferred to. The furthercode is executed as shown in Figure 5.5 which converts to target specific code and updates thebuffer and code-cache.

5.3.3 QEMU APIs

QEMU APIs are the abstraction techniques that provide a comparatively simple approach todevelop the custom machine. There are groups of APIs in QEMU used for different purposeswithin QEMU. Below are a few of the QEMU APIs that are essential to developing a custommachine.

• QEMUOpts: As described in the original commit in GitHub, QEMUOpts stores deviceparameters in a better way than un-parsed strings[22]. It is used to parse & store theconfigure files and command-line arguments. This API QEMUOpt maintains the key-valuepairs that belong to one device and QEMUOptList has the list of such devices, drives, andmachines.

• qdev: qdev maintains the device tree with a hierarchy of buses and devices. As mentioned inthe original commit, the theory here is that it should be possible to create a machine withoutthe knowledge of other specific devices[24]. Board init routines pass a set of arguments toeach device, requiring the board to know exactly which device it is dealing with. This fileprovides an abstract API for device configuration and initialization. Devices will generallyinherit from a particular bus (e.g. PCI or I2C) rather than this API directly. For example,qdev create is an API that creates a new device and initializes the device state structure.

• QOM: is abbreviated for QEMU Object Model[32][22] that is a framework that registersuser create-able types. QOM allows the creation and instantiating of user-defined types.

• QMP: QEMU Machine Protocol[2][22] is a JSON based Lightweight, text-based, easy toparse data format. QMP is mainly used for QEMU Monitor. Input will be read by mon-itor control read() and the function monitor json emitter(), as its name implies, it is usedby the Monitor to emit JSON output.

These are some of the API groups that are essential to extensively use QEMU functionalitiesand lessen the burden of the developer while programming such complex target hardware.

5.4 Development of STM32 modules

With reference to Figure 5.7 so far developing the kernel image has been discussed along with abrief explanation of the QEMU workflow and essential APIs employed. It is already mentionedin the introduction of this chapter that the sub-modules considered for the emulation are ARMprocessor Cortex-M4, Clock control, and GPIO. Along with these sub-modules of STM32F407,memory & bus emulation is also done which is the virtual memory and virtual bus for the guestOS as depicted in Figure 5.3.

In 2010, Andre Beckus emulated the STM32 P103 Pebble board[8] in QEMU. In 2014, AlistairFrancis developed the STM32F205 board [21] and in 2016, Martin Schroder developed the STM32429iboard based on Beckus’s STM32 Pebble board development[47]. Clock control emulation is in-fluenced by the STM32 pebble board & Schroder’s STM32F429i discovery board development.It provides the helper-functions to develop the complex clock control of STM32F407VEx. Thehelper-functions are studied and integrated in this project as header files. The helper-functionsare discussed in detail in Section 5.4.3. The clock control developed by Beckus does not use newQEMU APIs such as QOM and QObject, this has been improved in this project. The completeSTM32F407 machine code is divided into 4 code files as machine description file stm32f407ve scu.c,main file stm32f407xx.c, clock control stm32f407xx rcc.c and GPIO in stm32f407xx gpio.c.



STM32407Emulation

Kernel Image /Binary file

QEMU Sourcecode with Cortex-

M4 emulated

Vector TableMemoryMap inLinkerscript

Custom machineperipherals (clock,

GPIO, memory,bus)

Application Codewith Scheduler

Algorithm

Figure 5.7: Complete Development process involved in development of STM32F407 emulation

A definitive code structure has been maintained in all the development files of the STM32F407emulation. The code structure is the skeleton code generated when the QEMU APIs are used todefine the registers and their behavior. The code structure provides basic machine initialization,SOC creation with memory, I/O, bus interface, properties, and function to realize the machinebehavior. The code snippet is presented in Listing 5.5

12 s t r u c t stm32f407 soc { // d e f i n e the soc components3 } ;45 s t a t i c const MemoryRegionOps stm32 rogue mem ops = {67 } ;89 s t a t i c i n t s t m 3 2 r e a l i z e p e r i p h e r a l (ARMv7MState ∗cpu , SysBusDevice ∗dev , hwaddr

base , unsigned i n t i rqnr , Error ∗∗ er rp ) {1011 }12 s t a t i c void s t m 3 2 f 4 0 7 s o c i n i t f u n c ( Object ∗ obj ) {1314 }15 s t a t i c void s t m 3 2 f 4 0 7 s o c r e a l i z e ( DeviceState ∗dev soc , Error ∗∗ er rp ) {1617 }18 s t a t i c Property s t m 3 2 f 4 0 7 s o c p r o p e r t i e s [ ] = {19 DEFINE PROP STRING( ”cpu−type ” , s t r u c t stm32f407 soc , cpu type ) ,20 DEFINE PROP END OF LIST( ) ,21 } ;22 s t a t i c void s t m 3 2 f 4 0 7 s o c c l a s s i n i t ( ObjectClass ∗ k la s s , void ∗data )23 {24 DeviceClass ∗dc = DEVICE CLASS( k l a s s ) ;25 dc−>r e a l i z e = s t m 3 2 f 4 0 7 s o c r e a l i z e ;26 dc−>props = s t m 3 2 f 4 0 7 s o c p r o p e r t i e s ;2728 }29 s t a t i c const TypeInfo s t m 3 2 f 4 0 7 s o c i n f o = { // d e f i n e the dev i ce with name , bus ,

i n i t f unc t i on30 . name = TYPE STM32FXXX SOC,31 . parent = TYPE SYS BUS DEVICE,32 . i n s t a n c e s i z e = s i z e o f ( s t r u c t s tm32f407 soc ) ,33 . i n s t a n c e i n i t = s t m 3 2 f 4 0 7 s o c i n i t f u n c ,



34 . c l a s s i n i t = s t m 3 2 f 4 0 7 s o c c l a s s i n i t ,3536 } ;37 s t a t i c void s tm32 f407 soc types ( void )38 {3940 }41 t y p e i n i t ( s tm32 f407 soc types )

Listing 5.5: Skeleton code structure to define a custom machine

The basic code structure is maintained throughout the files of STM32F407 development. Theskeleton code defines the type of the machine as SOC or a register. When the type is SOC, aname, parent, size and init functions are defined. The name is a user create-able QOM. TheSOC is connected with a SYSBUS via parent. Devices are constructed in two stages, objectinstantiation by object initialization and device realization by DeviceState:realize property. Theinitialization of the object cannot fail, otherwise, the program terminates. Properties can be setto the SOC using the property function. The MemoryRegionOps facilitates an input and outputfunction by supplying read and write functions from binary files and to virtual memory of SOC.The MemoryRegionOps must be defined with the endianness of the SOC to facilitate the read andwrite in a certain endianness type. The STM32F407 operates with the Little Endian type.

After the skeleton code is in place for the sub-module, the further behavioral code and registerdefinitions of the sub-module are defined.

5.4.1 Adding STM32 argument to machine list in QEMU

The emulated hardware must be first recognizable by QEMU. The -machine argument takes themachines already defined in the code base of QEMU. Usually, the code for adding a machineto QEMU is merged into the main file of the hardware emulation which causes confusion whiledebugging. To avoid the confusion the description file stm32f407ve scu.c is handled separatelyfrom peripheral code.

1 s t a t i c void s t m 3 2 f 4 0 7 v e s c u i n i t ( MachineState ∗machine ) {2 s−>soc = qdev c rea te (NULL, ” stm32f407−soc ” ) ;3 q d e v p r o p s e t s t r i n g ( s−>soc , ”cpu−type ” , ARM CPU TYPE NAME( ” cortex−m4” ) ) ; //

a s s i g n cortex−m4 as the p r o c e s s o r4 o b j e c t p r o p e r t y s e t b o o l (OBJECT( s−>soc ) , true , ” r e a l i z e d ” , &e r r o r f a t a l ) ;56 MemoryRegion ∗sram =g new ( MemoryRegion , 1 ) ; // c r e a t e s new memory reg i on7 memory reg ion in i t ram ( sram , NULL, ” scu . sram” , 1024 ∗ 128 , &e r r o r f a t a l ) ; //

ram area de f ined with s i z e8 v m s t a t e r e g i s t e r r a m g l o b a l ( sram ) ;9 memory region add subregion ( get system memory ( ) , 0x20000000 , sram ) ;

10 // loads ke rne l o f maximum s i z e 2MB11 armv7m load kernel (ARM CPU( f i r s t c p u ) , machine−>k e r ne l f i l en a me , 2 ∗ 1024 ∗ 1024) ;12 }13 s t a t i c void s tm32 f407ve scu mach ine in i t ( MachineClass ∗mc) // d e f i n e s the

machine i n i t and d e s c r i p t i o n14 {15 mc−>desc = ”STM32F407 board with RAM” ;16 mc−> i n i t = s t m 3 2 f 4 0 7 v e s c u i n i t ;17 }18 DEFINE MACHINE( ” stm32f407ve scu ” , s tm32 f407ve scu mach ine in i t ) // machine i s

de f ined with i n i t i a l i z a t i o n c l a s s

Listing 5.6: Code snippet of details added in machine description file to add STM32F407 to QEMU

Listing 5.6 presents the machine description code for the STM32F407. The function DEFINEMACHINE on line 18 adds a name and a short description of the machine that is being emulated

in QEMU. The RAM size of 128*1024 is created and added as sub-region in system memory ataddress 0x200000000 as seen on lines 6 through 9. The Cortex-M4 CPU is passed as a qdevproperty to the SOC using ARM CPU TYPE NAME as seen on line 3. Kernel file / binary file



is passed as an argument to armv7m load kernel() function on line 11. The size of the kernel fileis set to 2MB and due to this size constraint, the binary file is preferred over the elf file. Binaryfiles are hex code and small in size. The description code adds the STM32F407 machine to thelist of the machines supported by QEMU under ARM architecture. Listing A.1 in the Appendixshows a list of machines supported by QEMU using the ARM architecture and stm32f407ve scuadded to the machine list with a description.

5.4.2 Cortex-M4 Processor and Memory Emulation

The Cortex-M4 is a 32-bit processor based on the 7th generation of ARM architecture and isincorporated as CPU into the STM32F4 series of hardware boards. The processor is emulated byQEMU for Texas Instruments board Stellaris. The emulated Cortex-M4 is used as CPU for theSTM32F407 emulation as shown in the machine description code in Listing 5.6.

The emulation code of the CPU begins in the cpu exec() as discussed in Section 5.3.2 QEMUworkflow. The CPU is a three stage pipeline processor where the instructions are fetched from TBthrough PC and decoded. The required action is performed after decoding and the internal stateof the CPU is updated. The BDT, TCG and chaining of TB optimizations are also done in thecpu exec() program. The SYSTICK timer of the CPU is supplied by the SOC timer according tothe clock tree of STM32F407 [52] and the same is realized in this project. The timer is suppliedto the CPU by clock control emulation. This is discussed in detail in Section 5.4.3.

The memory allocation must be handled carefully as the incorrect memory allocations can makethe system misbehave. For example, memory errors in the linker script can run into segmentationfaults. This occurs due to the startup code ending up in a different memory location than expecteddue to incorrect memory alignment/allocation. The complete memory space of STM32F407 is 4GBfrom 0x00000000-0xFFFFFFFF [52].

Figure 5.8: Memory mapping of STM32F407 memory space with remapping [52]

Figure 5.8 shows the memory mapping in STM32F407 hardware. The typically used remappingis to remap in the main flash memory where flash is aliased to address 0x00000000-0x000FFFFF.The memory emulation is handled in the main file stm32f407xx.c. Before diving into the memorystructure, the STM32f407 soc is defined with properties like armv7m ARM architecture. Thearmv7m is of type struct ARMv7MState defined in armv7m.h that supplies bitband2 functionalityto the SOC[52]. The SOC also is connected to the main sysbus and memory map I/O mmio. Any

2Bit-banding maps a complete word of memory onto a single bit in the bit-band region.



new peripherals added should be supplied with sysbus and must be defined in this struct as theperipheral belongs to the SOC.

In Listing 5.6 on line 6, shows how the memory area is created for SRAM. Similarly, FLASHand FLASH alias memory regions are created. The memory regions are added as sub region tothe system memory which holds the complete memory mapping of the SOC. The code snippet formemory emulation can be seen in Listing 5.7.

1 MemoryRegion ∗system memory = get system memory ( ) ;2 MemoryRegion ∗sram = g new ( MemoryRegion , 1) ;3 MemoryRegion ∗ f l a s h =g new ( MemoryRegion , 1) ;4 MemoryRegion ∗ f l a s h a l i a s = g new ( MemoryRegion , 1) ;56 memory reg ion in i t ram ( f l a sh , NULL, ”STM32F407 . f l a s h ” , FLASH SIZE , &e r r o r f a t a l

) ;7 m e m o r y r e g i o n i n i t a l i a s ( f l a s h a l i a s , NULL, ”STM32F407 . f l a s h . a l i a s ” , f l a sh , 0 ,

FLASH SIZE) ;89 v m s t a t e r e g i s t e r r a m g l o b a l ( f l a s h ) ;

1011 memory reg ion set readon ly ( f l a sh , t rue ) ;12 memory reg ion set readon ly ( f l a s h a l i a s , t rue ) ;1314 memory region add subregion ( system memory , FLASH BASE ADDRESS, f l a s h ) ;15 memory region add subregion ( system memory , 0 , f l a s h a l i a s ) ;1617 memory reg ion in i t ram ( sram , NULL, ”STM32F407 . sram” , SRAM SIZE , &e r r o r f a t a l ) ;18 memory region add subregion ( system memory , SRAM BASE ADDRESS, sram ) ;

Listing 5.7: Code snippet for memory emulation

Once the complete base memory is setup, similarly the peripheral memory is established as perthe memory address specified for the particular peripheral[52]. The peripheral emulated for thisproject and the memory details are depicted in Table 5.1

Peripheral Name Boundary AddressReset and Clock Control (RCC) 0x4002 3800 - 0x4002 3BFFGPIOA 0x4002 0000 - 0x4002 03FFGPIOB 0x4002 0400 - 0x4002 07FFGPIOC 0x4002 0800 - 0x4002 0BFFGPIOD 0x4002 0C00 - 0x4002 0FFFGPIOE 0x4002 1000 - 0x4002 13FFGPIOF 0x4002 1400 - 0x4002 17FFGPIOG 0x4002 1800 - 0x4002 1BFFGPIOH 0x4002 1C00 - 0x4002 1FFFGPIOI 0x4002 2000 - 0x4002 23FF

Table 5.1: Peripheral names and Boundary addresses to be specified for memory emulation

The GPIO and clock control are specified with a sysbus connection in the stm32f407 socstructure. In the memory emulation, it is also ensured that any memory accesses beyond 0xffffffffare caught and handled. These accesses are handled in rogue mem function. If the out of memoryaccesses are not handled, QEMU terminates with a segmentation fault.

5.4.3 Clock Control Emulation

A real-time device is expected to be not only logically accurate but also time-accurate. A senseof time is required for the controller to synchronize its own tasks and produce a logically correctanswer. The memory, CPU, I/O, and other peripherals also must be synchronized and time-aware.A single System Clock (SYSCLK) is employed and a clock tree is created around the SYSCLK



to supply the clock to other elements of the STM32F407 hardware board. A part of the clocktree is represented in Figure 5.9. The main clock SYSCLK is configurable through three clocks.The High-Speed Oscillator(HSE) clock is 25MHz, the High-Speed Internal(HSI) clock is 16MHzand the Phase-Locked Loop(PLL) clock supplies 168MHz. When one of the clocks is driving theSYSCLK, it cannot be interrupted. The chosen clock is further divided by a pre-scaler to supplyto the peripherals. The Cortex-M4 can be supplied with SYSCLK directly or pre-scaled to 8.

Figure 5.9: Basic clock circuitry for the STM32F407 with ARM processor [29]

The controllers are run at a clock frequency of 16MHz and the same frequency is used for theCortex-M4 clock (SYSTICK). The peripheral Clock (HCLK), which supplies the clock signal toGPIOs is not pre-scaled, supplying 16MHz clock frequency to the GPIOs. To emulate the clockcontrol, the clock system of STM32F407 is analyzed for the behavior logic and the clock systemof QEMU is analyzed to use the QEMU functionalities for the emulation of the behavior.

Clock Registers of STM32:

Clock registers are used in STM32F407 to program the clock tree. For clock emulation, clockregisters are carefully chosen to emulate the basic clock behavior for STM32F407. Figure 5.9shows the clock tree of the emulated clock of STM32F407 emulation. The complete clock registermap is presented in Appendix B.1.

The clock registers implemented take care of SYSTICK, SYSCLK and HCLK. Each registerconsists of reset value, address offset and bits that are configurable. The clock source is determinedby the registers RCC CR (Control Register) and RCC CFGR(Configuration Register) registers.The detailed register definition is provided in Figure B.3 and B.4 in Appendix. The implementationof these registers is in stm32f407xx rcc.c is as shown in Listing B.1 in Appendix. The reset valueof the control register is 0x00000083 which sets the HSION bit in RCC CR register.

When the device is powered up, the HSE and PLL are disabled. The SW bit in RCC CFGRis set to 00, configuring the clock system to HSI clock frequency, 16MHz. The HSE clock can beenabled by setting the 16th-bit HSE ON to 1 and wait until the HSE Rdy is ready in the RCC CRregister. The clock source for the PLL is set using the PLLSRC bit while the PLL frequency is setby programming the PLLM, PLLN and PLLP bits in the phase lock loop configuration register(RCC PLLCFGR). For peripherals, there are three bus clock speed configurations. AdvancedHigh-Speed Bus (AHB) and two Advanced Peripheral Bus (APBx) as depicted in Figure 5.9. Theclock frequency for peripherals is selected through the RCC CFGR register.

Table 5.2 shows the different configurations possible through the RCC CR and RCC CFGR



bits. The peripheral buses operate with the chosen System Clock frequency of 16 MHz. TheAPB1 employs pre-scalers to supply the specific clock frequency for peripherals like the UART.The GPIOs operate with the AHB bus that supplies the maximum frequency of 16MHz.

HPRE PPRE1,2 SW0xxx: SYSCLK 0xx: HCLK 00: HSI1000: SYSCLK/2 100: HCLK/2 01: HSE1001: SYSCLK/4 101: HCLK/4 10: PLL1010: SYSCLK/8 110: HCLK/8 11: Not allowed1011: SYSCLK/16 111: HCLK/161100: SYSCLK/641101: SYSCLK/1281110: SYSCLK/2561111: SYSCLK/512

Table 5.2: Different clock settings that can be used for STM32F407 functioning

To enable the peripheral device, the peripheral must be attached to the appropriate bus. TheGPIO operates with the AHB bus with the clock frequency of 16MHz. So the pre-scaler is 1 forthe AHB clock frequency. The pre-scaler can be selected from the RCC AHB1ENR from the RCCregister map as depicted in Figure B.5. The reset value of the register is 0x00100000, where allthe clocks for GPIO ports are set to 0 and the bits are set and cleared by the application logic.

Clock Implementation in QEMU:

QEMU operates on its own clock system to carry out various functions such as translation of in-structions from guest specific to host specific code using BDT and TCG optimizations. The clockreference for QEMU is derived from the real physical hardware clock ticks. Timers, specificallyQEMUTimers provide a means to call a subroutine (callback) after a certain amount of time hasbeen elapsed by passing an opaque pointer to a routine. When the timers elapse, they call theircallback and do nothing further unless they are re-armed. The QEMU clocks are of QEMUClock-Type enum, in which following types of clocks are available defined in timer.h invoked in QEMUmain loop vl.c There are three different clocks from which the QEMUTimers can be derived.

• QEMU CLOCK REALTIME : The Real Time (RT) clock, which runs even when theVM is stopped, with a resolution of 1000 Hz. This clock should not be used for executionsthat change the VM state.

• QEMU CLOCK VIRTUAL: The virtual clock, which only runs when the VM is running,at a high resolution.

• QEMU CLOCK HOST : The host clock should be used for device models that emulateaccurate real time sources. It will continue to run when the virtual machine is suspended,and it will reflect system time changes the host may undergo.

• QEMU CLOCK VIRTUAL RT : This RT clock is used for icount warp. Outside icountmode, this clock is the same as QEMU CLOCK VIRTUAL. In icount mode, this clockcounts nanoseconds while the virtual machine is running. It is used to increase QEMUCLOCK VIRTUAL while the CPU is sleeping and thus not executing instructions.

The diagram below depicts the QEMUTimers and its structure to function and maintain arecord of timers running. The list of running timers is kept in a QEMUTimerList. The trackof each QEMUTimerLists is maintained by Clock and keeps a list (purple line). Each user alsomaintains a QEMUTimerListGroup.

The clock needs to keep a track of all the QEMUTimerLists attached to that clock, and forthat purpose maintains a list of them (purple line in the diagram). Each user of timers maintains



Figure 5.10: Complete QEMU timer diagram [13]

a QEMUTimerListGroup. Each QEMUTimerList maintains a pointer to the clock to which itis connected (orange line). It contains a pointer to the first active timer. The active timers arearranged in order of expiry, with the timer expiring soonest at the start of the list, linked by theQEMUTimerList object (blue line). Each QEMUTimer object contains a link back to its timer list(green line) for manipulation of the lists. While QEMU supports maintaining the clock lists andalso generates clock ticks to the resolution of nanoseconds and milliseconds, it does not supportin creating a clock tree for the SOC. Instead when the guest machine programs a timer device(Clock Control), the model of the timer device sets up an internal QEMU timer to fire after theappropriate duration and the handler for that then raises the interrupt line for emulating the clockcontrol behavior.

system clock scale updates the scale for the QEMUTimer as shown in Figure 5.10. Thesystem clock scale is the ratio of QEMU clock ticks to system/external clock ticks. An IRQ,hclk upd irq of type qemu irq is instantiated to update the scales to the QEMU clock system. TheIRQ handler handles updates to the HCLK frequency. The pre-scalers are of great importancehere as only one clock frequency is enough to manipulate the QEMUTimers. The scaled frequencyis computed by the STM32F407 clock tree to supply it to the peripherals.

Helper Functions:

The helper functions were developed by Andre Beckus for the development of the STM32P103Pebble board and have been used extensively for the development of the STM32F407 board.All the helper functions are defined in stm32fxxx clktree.c. The helper function has struct clk,which has input frequency, output frequency, maximum frequency, multiplier and divisor membersthat take these values for particular peripheral and calculate the output frequency based on thepre-scaler values. The clktree recalc output freq is one such function that calculates the outputfrequency based on the pre-scaler input requested by the application logic as shown in Listing B.2



in Appendix.

Behavioral Implementation of Clock Control:

The clock behavior is implemented based on the register maps shown in Listing B.1 in Appendix,using helper functions and QEMU timer implementation. Setting up a clock tree involves a pro-cedure of configuring the bits to keep the complete system well informed and allocating particularclock frequency to sub-modules with or without pre-scaling. As discussed in the section above,RCC CR, RCC CFGR, and RCC AHB1ENR are the registers required to set clock frequency forprocessor and GPIOs. The clock frequency for the GPIO implementation is discussed in the GPIOemulation Section 5.4.4.

The clock control is registered as a register type as it is a peripheral, a sub-module of theSOC. Similar to the skeleton code in the main file, a QOM property is defined with a name,parent supplying the bus to clock control and initialization function is defined. A structurestruct stm32f407xx rcc is instantiated with all the clocks HCLK, PCLK1, PCLK2, SYSCLK, HS-ICLK, HSECLK and registers RCC CIR, RCC APB1ENR, RCC APB2ENR, RCC AHB1ENRand register fields RCC PLLCFGR PLLM, RCC PLLCFGR PLLP and RCC PLLCFGR PLLNare defined. This structure now represents the complete clock tree and a connection must beestablished with the logic as illustrated in the reference manual [52]. Every register defined inthe struct stm32f407xx rcc is provided with read and write function that receives the hardwareoffset argument hwaddr offset which is defined for each register. The hardware offset can be seenin register map in Appendix A in address offset column and in Listing B.1 for each register. Thecomplete register implementation is presented in the Appendix B.3. The implementation of theGPIO clock is discussed in Section 5.4.4.

5.4.4 General Purpose Input/Output Emulation

The STM32F407 board has 9 General Purpose Input/Output(GPIO) ports with 16 pins each.Every port can be individually configured by application logic. Each general-purpose I/O porthas four 32-bit configuration registers GPIOx MODER,GPIOx OTYPER, GPIOx OSPEEDR andGPIOx PUPDR), two 32-bit data registers (GPIOx IDR and GPIOx ODR), a 32-bit set/reset re-gister (GPIOx BSRR), a 32-bit locking register (GPIOx LCK R) and two 32-bit alternate functionselection register (GPIOx AFRH and GPIOx AFRL). In this project, modes MODER, IDR andBSRR are implemented. The other configurations such as Pull-up or pull-down configurationsare hardware related and cannot be realized. Whereas, the AFHR and AFRL need additionalDAC and ADC implementation. The GPIOx ODR register cannot be implemented as it requiresQEMU interfacing with another device. The complete register map can be found in AppendixB.2.

Clock Implementation for GPIO:

The clock implementation for GPIO is handled in stm32f407xx rcc.c file. To begin with, each GPIOport from A to I are assigned with a clock by using the helper function in stm32fxxx clktree.c Clkclktree create clk as shown in Listing 5.8. For device initialization all the clocks are set to initialvalue 0.

123 // Helper func t i on to c r e a t e a c l o ck in stm32fxxx . c4 Clk c l k t r e e c r e a t e c l k (5 const char ∗name ,6 u i n t 1 6 t m u l t i p l i e r ,7 u i n t 1 6 t d i v i s o r ,8 bool enabled ,9 u i n t 3 2 t max output freq ,

10 i n t s e l e c t e d i n p u t ,11 . . . )



1213 // Use o f he lpe r func t i on in stm32f407xx rcc . c to c r e a t e c l o ck f o r each GPIO

i n i t i a l i z e d to 0 f o r dev i ce i n i t i a l i z a t i o n .14 /∗ Per iphe ra l c l o c k s ∗/15 s−>PERIPHCLK[STM32 GPIOA] =16 c l k t r e e c r e a t e c l k ( ”GPIOA” , 1 , 1 , f a l s e , CLKTREE NO MAX FREQ, 0 , s−>HCLK,

NULL) ;17 s−>PERIPHCLK[ STM32 GPIOB ] =18 c l k t r e e c r e a t e c l k ( ”GPIOB” , 1 , 1 , f a l s e , CLKTREE NO MAX FREQ, 0 , s−>HCLK,

NULL) ;19 s−>PERIPHCLK[STM32 GPIOC] =20 c l k t r e e c r e a t e c l k ( ”GPIOC” , 1 , 1 , f a l s e , CLKTREE NO MAX FREQ, 0 , s−>HCLK,

NULL) ;21 s−>PERIPHCLK[STM32 GPIOD] =22 c l k t r e e c r e a t e c l k ( ”GPIOD” , 1 , 1 , f a l s e , CLKTREE NO MAX FREQ, 0 , s−>HCLK,

NULL) ;23 s−>PERIPHCLK[ STM32 GPIOE ] =24 c l k t r e e c r e a t e c l k ( ”GPIOE” , 1 , 1 , f a l s e , CLKTREE NO MAX FREQ, 0 , s−>HCLK,

NULL) ;25 s−>PERIPHCLK[ STM32 GPIOF ] =26 c l k t r e e c r e a t e c l k ( ”GPIOF” , 1 , 1 , f a l s e , CLKTREE NO MAX FREQ, 0 , s−>HCLK,

NULL) ;27 s−>PERIPHCLK[STM32 GPIOG] =28 c l k t r e e c r e a t e c l k ( ”GPIOG” , 1 , 1 , f a l s e , CLKTREE NO MAX FREQ, 0 , s−>HCLK,

NULL) ;29 s−>PERIPHCLK[STM32 GPIOH] =30 c l k t r e e c r e a t e c l k ( ”GPIOH” , 1 , 1 , f a l s e , CLKTREE NO MAX FREQ, 0 , s−>HCLK,

NULL) ;31 s−>PERIPHCLK[ STM32 GPIOI ] =32 c l k t r e e c r e a t e c l k ( ”GPIOI” , 1 , 1 , f a l s e , CLKTREE NO MAX FREQ, 0 , s−>HCLK,

NULL) ;

Listing 5.8: Code snippet to create clock for GPIOs

Once the clocks are created with initial values the application logic requests to set the clockfrequency for the GPIOs. The clock frequency for GPIO is not pre-scaled as it operates on theAHB bus. The GPIO clock frequency is the same as the clock frequency of the SYSCLK whichis 16MHz. For any other peripherals, pre-scaling is done and the clock frequency is assignedaccordingly. The code snippet to set clock frequency for GPIOs is depicted in Listing 5.9

12 // read the value reques ted by a p p l i c a t i o n l o g i c from . read func t i on3 s t a t i c u i n t 3 2 t stm32 rcc RCC AHB1ENR read ( s t r u c t stm32f407xx rcc ∗ s )4 {5 re turn s−>RCC AHB1ENR;6 }78 // Set the c l o c k s f requency f o r the c l o c k s c rea ted in i n i t i a l i z a t i o n through . wr i t e

func t i on9 s t a t i c void stm32 rcc RCC AHB1ENR write ( s t r u c t stm32f407xx rcc ∗ s , u i n t 3 2 t

new value , bool i n i t )10 {1112 c l k t r e e s e t e n a b l e d ( s−>PERIPHCLK[ STM32 GPIOI ] , IS BIT SET ( new value ,

RCC AHB1ENR GPIOIEN BIT) ) ;13 c l k t r e e s e t e n a b l e d ( s−>PERIPHCLK[STM32 GPIOH] , IS BIT SET ( new value ,

RCC AHB1ENR GPIOHEN BIT) ) ;14 c l k t r e e s e t e n a b l e d ( s−>PERIPHCLK[STM32 GPIOG] , IS BIT SET ( new value ,

RCC AHB1ENR GPIOGEN BIT) ) ;15 c l k t r e e s e t e n a b l e d ( s−>PERIPHCLK[ STM32 GPIOF ] , IS BIT SET ( new value ,

RCC AHB1ENR GPIOFEN BIT) ) ;16 c l k t r e e s e t e n a b l e d ( s−>PERIPHCLK[ STM32 GPIOE ] , IS BIT SET ( new value ,

RCC AHB1ENR GPIOEEN BIT) ) ;17 c l k t r e e s e t e n a b l e d ( s−>PERIPHCLK[STM32 GPIOD] , IS BIT SET ( new value ,

RCC AHB1ENR GPIODEN BIT) ) ;18 c l k t r e e s e t e n a b l e d ( s−>PERIPHCLK[STM32 GPIOC] , IS BIT SET ( new value ,

RCC AHB1ENR GPIOCEN BIT) ) ;



19 c l k t r e e s e t e n a b l e d ( s−>PERIPHCLK[ STM32 GPIOB] , IS BIT SET ( new value ,RCC AHB1ENR GPIOBEN BIT) ) ;

20 c l k t r e e s e t e n a b l e d ( s−>PERIPHCLK[STM32 GPIOA] , IS BIT SET ( new value ,RCC AHB1ENR GPIOAEN BIT) ) ;

2122 // c o l l e c t the new value23 s−>RCC AHB1ENR = new value ;242526 }

Listing 5.9: Code to assign clock frequency to GPIOs requested by the application logic

Implementation of MODER, IDR, and BSRR:

A GPIO is an uncommitted digital signal pin on the integrated/electronic circuit board whosebehavior, including whether it acts as input or output, is controllable by the user at run time.This basic implementation of the GPIO is fulfilled in this project. Each behavior of the GPIO portis configured by the application logic. Similarly to the clock control, the GPIO has registers withbits allocated for particular configurations and store the new value on the GPIO data registers.The three registers that are implemented are MODER, IDR, and BSRR.

The GPIO emulation logic is defined in another file stm32f407xx gpio.c and added to make-file.obj for the compiler to compile for the armv7m architecture and create a .object file for thesame. The GPIO emulation follows the skeleton code structure as defined in Listing 5.5 Theapplication logic configuration is read from .read function into stm32f407xx gpio read. The GPIOread implements the read of every configuration requested by application logic as shown in Listing5.10.

1 s t a t i c u i n t 6 4 t s tm32f407xx gp io read ( void ∗opaque , hwaddr addr , unsigned i n t s i z e) {

2 s t r u c t stm32f407xx gpio ∗ s e l f = ( s t r u c t stm32f407xx gpio ∗) opaque ;3 i f ( s i z e !=4) {4 GPIO ERROR ( ” gpio read o f !=4 bytes not implemented\n” ) ;5 }6 switch ( addr ) {7 case 0x00 : r e turn s e l f −>regs−>MODER; break ;8 case 0x04 : r e turn s e l f −>regs−>OTYPER; break ;9 case 0x08 : r e turn s e l f −>regs−>OSPEEDR; break ;

10 case 0x0c : r e turn s e l f −>regs−>PUPDR; break ;11 case 0x10 : r e turn s e l f −>regs−>IDR ; break ;12 case 0x14 : r e turn s e l f −>regs−>ODR; break ;13 case 0x18 : r e turn s e l f −>regs−>BSRR; break ;14 case 0x1c : r e turn s e l f −>regs−>LCKR; break ;15 case 0x20 : r e turn s e l f −>regs−>AFRL; break ;16 case 0x24 : r e turn s e l f −>regs−>AFRH; break ;17 d e f a u l t : {18 GPIO ERROR( ”Unknown o f f s e t f o r gpio r e g i s t e r 0x%08x\n” , ( u i n t 3 2 t ) addr ) ;19 }20 }21 re turn 0 ;22 }

Listing 5.10: Read function for the application logic requests for configuration

MODER is a 32 bit register for every GPIO port (GPIOx MODER) where x = A..I/J/K asdepicted in Figure B.8. There are four modes for each pin in GPIO port and hence two bits eachare dedicated to one pin of a GPIO configuration.

IDR and ODR are the input and output data registers. The output generated by theapplication logic is stored in the ODR registers and input received from the external interface isstored in IDR registers. As an external interface is currently out of scope for this project, theIDR data register is not implemented. The read function for the IDR and ODR is handled as



shown in Listing 5.10. The write function is implemented in stm32f407xx gpio write. The IDRbits are read-only and can be accessed in word mode only. They contain the input value of thecorresponding I/O port. The ODR bits can both be read and written by application logic. TheIDR and ODR registers are depicted in Figure B.9 and B.10 in Appendix respectively.

The IDR and ODR cannot be read/written by configuring them as input/output before access-ing the registers. The address offset as shown in Appendix B.2 is provided by hwaddr argumentfrom the application logic. Based on the address offset the particular register is accessed. Theparticular GPIO and registers are defined as shown in Listing 5.11

1 #d e f i n e STM32FXXX NUM GPIOS 923 s t r u c t s tm32 fxxx state {4 s t r u c t s tm32 fxxx gp io s ta t e {5 union {6 u i n t 3 2 t r eg s [ 1 0 ] ;7 s t r u c t {8 u i n t 3 2 t MODER;9 u i n t 3 2 t OTYPER;

10 u i n t 3 2 t OSPEEDR;11 u i n t 3 2 t PUPDR;12 u i n t 3 2 t IDR ;13 u i n t 3 2 t ODR;14 u i n t 3 2 t BSRR;15 u i n t 3 3 t LCKR;16 u i n t 3 2 t AFRL;17 u i n t 3 2 t AFRH;18 } ;19 } ;20 } GPIO[STM32FXXX NUM GPIOS ] ;

Listing 5.11: Definition of GPIOs and their state in the stm32f407xx gpio.c

The nested structure above allows accessing the required bit which represents a pin in theparticular register of the specific GPIO. The implementation of the MODER, ODR, and BSRRcan be seen in Listing 5.12. The BSRR is Bit Set and Reset register which is used to set and resetthe bits of the ODR register. These bits are write-only and can be accessed in word, half-word orbyte mode. The implementation is depicted in Listing 5.12

1 switch ( addr ) {2 case 0x00 : { //MODER c o n f i g u r a t i o n3 u i n t 3 2 t valx= va l ˆ s e l f −>s ta te−>GPIO[ s e l f −>p o r t i d ] .MODER; // checks

which b i t s are changed4 f o r ( i n t c=0; c < 16 ; c++){5 i f ( va lx & (3 << ( c ∗ 2) ) ) { // s h i f t s two t imes as r equ i r ed by the

c o n f i g u r a t i o n6 const char ∗modestr [ ] = {7 ” Input ” ,8 ”Output” ,9 ”AF” ,

10 ”Analog”11 } ;12 GPIO TRACE ( ”GPIO%c P%c%d : mode s e t to %s \n” , ’A ’ + s e l f −>

por t id , ’A ’ + s e l f −>por t id , c , modestr [ ( va l >> ( c ∗ 2) )& 3 ] ) ;

13 } // s h i f t e d l e f t to i d e n t i f y the c o n f i g u r a t i o n chosen1415 }16 s e l f −>regs−>MODER = val ;17 }break ;18 case 0x14 : { // ODR c o n f i g u r a t i o n19 f o r ( i n t c = 0 ; c < 16 ; c++){20 u i n t 8 t mode = ( s e l f −>regs−>MODER >> ( c ∗ 2) ) & 3 ;21 i f (mode != 1) { // i f mode not output22 GPIO TRACE( ”GPIO%c P%c%d : wr i t i ng to ODR has no e f f e c t . Pin not

con f i gu r ed as output (mode = %d) \n” , ’A ’ + s e l f −>por t id ,’A ’ + s e l f −>por t id , c , mode) ;



23 }24 e l s e {25 s e l f −>regs−>ODR = val ;26 }2728 }2930 } break ;3132 case 0x18 : { // BSRR c o n f i g u r a t i o n33 f o r ( i n t c = 0 ; c < 16 ; c++){34 bool s e t = ( va l >> c ) & 1 ;35 bool r e s e t = ( va l >> (16 + c ) ) & 1 ;36 i f ( s e t && r e s e t ) {37 GPIO ERROR( ”GPIO%c P%c%d : BS and BR both s e t \n” , ’A ’ + s e l f −>

por t id , ’A ’ + s e l f −>por t id , c ) ;38 } e l s e i f ( s e t ) {39 s e l f −>regs−>ODR |= (1 << c ) ;40 GPIO TRACE( ”GPIO%c P%c%d : wr i t e va lue 1\n” , ’A ’ + s e l f −>por t id

, ’A ’ + s e l f −>por t id , c ) ;41 } e l s e i f ( r e s e t ) {42 s e l f −>regs−>ODR &= ˜(1 << c ) ;43 GPIO TRACE( ”GPIO%c P%c%d : wr i t e va lue 0\n” , ’A ’ + s e l f −>por t id

, ’A ’ + s e l f −>por t id , c ) ;44 } e l s e {45 //GPIO ERROR(”GPIO%c P%c%d : BSRR: no ac t i on taken\n” , ’A ’ +

s e l f −>por t id , ’A ’ + s e l f −>por t id , c ) ;46 }47 }48 s e l f −>regs−>BSRR = 0 ;49 } break ;

Listing 5.12: Code snippet of MODER, IDR and ODR emulation

The GPIO is a simpler module compared to clock control as it involves mostly the developmentof behavior of GPIO. The clock control and CPU interactions are already handled in the main fileand clock control modules. The testing of the emulated hardware is carried out in Chapter 6 toanalyze the claims made in favor of emulation over the simulation.

5.5 Collective overview of clock behavior for GPIO and pro-cessor

The clock implementation for each sub-modules of STM32F407 has been discussed separately inthis chapter. It is important to have a collective perspective of the working of the clock emulation.The clock emulation in STM32F407 caters to processor and GPIO. The clock frequency of 16MHzis configured from the binary/firmware configuration and is supplied to SYSCLK which is themain clock. The SYSCLK is further forked into the clock tree and then provided to GPIO viaHCLK with or without pre-scaling depending on the configuration. In real hardware, the SYSCLKfrequency is supplied to SYSTICK, that is, the processor clock as well. The same behavior has beenimplemented in this project but even though the 16MHz frequency is provided to the SYSTICK,the guest CPU Cortex-M4 is not really bound to this clock frequency. The 16MHz clock frequencyis simply an annotation for the processor. The guest CPU executes instructions as fast as it canto compensate for the execution overhead. Forcing the guest CPU to abide by the configuredfrequency is inefficient, as the guest CPU is already slow due to the overhead such as translationof instructions from guest CPU architecture to host CPU architecture. The BDT, TCG, andchaining of TBs’ optimizations translate the guest instructions to host instructions as fast as theycan.

This accelerated execution is further synchronized with the configured clock frequency of peri-pherals, by synchronizing on the SYSCLK (16MHz). The guest CPU translates and executes



the independent instructions as fast as it can but executes peripheral dependent instructions atconfigured SYSCLK frequency.


The expectation from the emulation as opposed to simulation is providing the RTSW a simulatedenvironment that mimics the real hardware environment. Unlike simulation which runs on thedesktop PC, emulation provides a CPU, memory, and peripherals of the real hardware running onthe desktop PC. QEMU emulates the CPU and boots the firmware similar to the real hardware.The simulation happens at the CPU instruction and hardware interface level instead of at thehigh-level language API level. The full system emulation provides a complete real hardwareenvironment. In this case, the RTSW is unaware that it is not interacting with real hardware.This kind of emulation facilitates finding bugs in lower layers of the software stack and can bereproduced, which is unlikely in simulated test environments. CPU architecture-specific bugssuch as stack and memory defects can also be reproduced using full system emulation. The maindisadvantage of full-system emulation is that the performance overhead is higher since simulationhappens at the CPU instruction level. Programs consisting of many CPU instructions makeemulation performance-sensitive. A more powerful guest CPU can result in higher overhead andCortex-M4 is a powerful CPU that can bring down the performance of the emulation.


Chapter 6

Performance Analysis andEvaluation of the Emulatedplatform

A Substantial amount of performance tests have been carried out by researchers and students toanalyze how viable is QEMU to be deployed in industrial test environments. In most of the researchstudy, QEMU’s performance evaluation tests are executed with benchmarking tools. Benchmarktesting is the process of load testing a component or an entire end to end system to determine theperformance characteristics of the application. The benchmarks are used to test the OS and theCPU performance by running implementations of different algorithms like list processing, matrixmanipulation, state machine, and CRC which provide the workload commonly seen in embeddedapplications. The benchmark utilized in one such research study, compares the number of iterationsmade by physical hardware with emulated QEMU hardware and generates a score. The studyconducted in the research paper shows that QEMU is 7 times slower when compared to realhardware [34]. Another research study utilized QEMU to inject memory, undefined instructionsfaults to analyze the reliability of operating systems executable code, stack space and dynamicallyallocated data [18].

However, such benchmarks show that QEMU is slow compared to physical hardware. In suchevaluations, QEMU is used as a hypervisor running a GPOS. In this thesis, QEMU is evaluated as abare-metal hypervisor without a guest OS, emulating a hardware board STM32 as guest hardware.Custom benchmarks are produced as firmware with RTSW to evaluate the emulated hardwarefor functional and real-time performance. Additionally extra-functional properties modularity,scalability, reliability, and availability are considered for the UT and IT criterion. The tests arerun on the emulated STM32 hardware.

Experimental setup:

The hypervisor QEMU is installed and executed on the desktop processor with four Intel i5processors of x86-64 architecture and 4GB RAM. Ubuntu 16.04 is the general-purpose host OS. Inthis experiment, QEMU is used as a hypervisor without a guest OS (bare-metal) and STM32F407veas emulated guest hardware with one ARM architecture, Cortex-M4 processor.

6.1 Modularity test

One of the challenges in Embedded testing is the unit testing with the physical hardware. Inter-national standards such as IEC-61508, ISO-26262, and DO-178B require unit testing for a givenfunctional safety level. The hardware unavailability can result in hidden defects as discussed in


CHAPTER 6. PERFORMANCE ANALYSIS AND EVALUATION OF THE EMULATEDPLATFORM

Chapter 2. Even when the physical hardware is available, separation of concern1 is challengingto achieve with the physical hardware. Physical hardware is an unalterable component of thetest environment, requiring a complete software that perceives all the peripherals of the physicalhardware. Any peripheral not addressed in the software leads to an exception.

Emulation of the physical hardware provides complete control over the functioning of theemulated hardware. In this project, the emulated hardware consists of clock control, a processorand GPIO peripherals that do not comprise into complete target hardware. QEMU supportsvarious internal logging and debugging facilities. One of the logging techniques involves addingthe unimplemented peripherals or registers in the specific peripherals to the unimplemented listlog.

The unimplemented peripherals of the target hardware can be handled in the QEMU sourcecode as shown in Listing 6.1. Qemu log mask is a QEMU’s API which adds the warning tothe log of UNIMP command in QEMU’s monitor. The list of unimplemented peripheral registerscan be seen when command qemu-system-arm -machine stm32f407ve scu -d unimp -kernel

stm32407.bin is run as listed in Listing C.1. Since the unimplemented registers of the peripheralsare captured by the QEMU source code, there are no errors introduced. The peripherals that arenot implemented are unknown to the emulated hardware and if the software does not access theadditional peripheral there are no errors generated.

12 #d e f i n e WARN UNIMPLEMENTED( new value , mask , r e s e t v a l u e ) \3 i f ( ! IS RESET VALUE( new value , mask , r e s e t v a l u e ) ) { \4 qemu log mask (LOG UNIMP, ”Not implemented : RCC ” #mask ” . Masked value : 0x

%08x\n” , ( new value & mask) ) ; \5 }67 #d e f i n e WARN UNIMPLEMENTED REG( o f f s e t ) \8 qemu log mask (LOG UNIMP, ”STM32f407xx rcc : unimplemented r e g i s t e r : 0x%x” , (

i n t ) o f f s e t )

Listing 6.1: Code in the QEMU source code avoid segmentation faults for missing peripherals oftarget hardware

While QEMU addresses the separation of concern property smoothly, it should be carefullytaken into account that all the dependencies or interfaces between the modules are handled intothe emulation code. For example, the pull-up/pull-down mode of GPIO is not implemented in thecurrent emulation code. The repercussions must be taken into account and should be analyzedif the system behaves differently when the implementation is in place. Along with behavioralcorrectness, the logical correctness is also important to utilize the modularity feature offered byQEMU. The logical correctness is verified in the functionality test in Section 6.2.

6.2 Functionality test

This section is designed to test the different input configurations for the emulated hardware toverify the logical correctness of the GPIO, and CPU peripherals on a bare-metal system. The testcases are designed keeping in mind the three said peripherals as depicted in Table 6.1.

1separation of concerns is a design principle for separating a computer program into distinct sections, so thateach section addresses a separate concern.



Input OutputTestcaseno.

GPIO CPU Logical Correctness

1Toggle oneof the GPIO pin

- -Toggling shouldbe observed

2Toggle multipleGPIO pins of a Port


3Toggle 2 GPIO pinsof 2 different ports


4 Toggle any pin Addition Operation

Pin togglingCPU operationmust beobserved

Table 6.1: Test case scenarios to test CPU Cortex-M4 and GPIO in combination

6.2.1 Test cases

The test cases are curated to verify the overall logical correctness of the emulated hardwaredeveloped. The application logic (ESW) is developed in the Atollic TrueSTUDIO for STM32development studio. The HAL driver and CMSIS library are compiled together with the startupcode, linker script, and c code (ESW) to generate a binary file. The input and expected outputfor each test execution on the emulator is defined in Table 6.1. The test cases are only verifiedfor logical behavior and not for the timing performance of the emulated hardware. The timingperformance is verified separately in Section 6.4.

Test case 1: The test case is designed to verify the functioning of the GPIO. The GPIO portA pin 10 (GPIOA P10) is configured as an output pin and other ports are configured to the analogmode by default. The clock frequency as shown in Figure 5.9 can be configured in three clockfrequencies. In this test case the clock is successfully set to 16MHz clock frequency. A simple ccode to toggle the GPIOA PA10 is written as shown in Listing 6.2

1 whi l e (1 )2 {3 // HAL func t i on to t o g g l e GPIO pin4 HAL GPIO TogglePin (GPIOA, GPIO PIN 10 ) ;56 // de lay o f 100ms7 HAL Delay (100) ;8 }

Listing 6.2: Simple application code to test peripherals implemented

Test result: The test case is passed and the emulator successfully outputs toggling of theGPIO pin PA10 with clock frequency 16MHz. The output of the execution is listed in Listing C.2in Appendix.

Test case 2: The test case is designed to verify the logical correctness of the GPIO withmultiple pins functioning together. The clock is successfully set to 16MHz. Listing 6.3 shows theapplication logic to toggle multiple GPIO pins of port A.

1 whi l e (1 )2 {3 // Toggle p ins 5 ,6 ,9 ,10 ,11 o f port A4 HAL GPIO TogglePin (GPIOA, GPIO PIN 10 ) ;5 HAL Delay (100) ;6 HAL GPIO TogglePin (GPIOA, GPIO PIN 5 ) ;



7 HAL Delay (100) ;8 HAL GPIO TogglePin (GPIOA, GPIO PIN 6 ) ;9 HAL Delay (100) ;

10 HAL GPIO TogglePin (GPIOA, GPIO PIN 9 ) ;11 HAL Delay (100) ;12 HAL GPIO TogglePin (GPIOA, GPIO PIN 11 ) ;13 HAL Delay (100) ;14 }

Listing 6.3: Application code to toggle multiple pins of same port A

Test result: The test case is passed and the emulator successfully outputs toggling of theGPIO pin PA5, PA6, PA9, PA10, PA11. The output is listed in Listing C.3 in Appendix.

Test case 3: In this test case, PA6 and PE12 are configured as output pins. This test caseverifies the toggling of two different pins of different ports. Listing 6.4 shows the application logicto toggle GPIO pin of ports A and E toggling.

1 whi l e (1 )2 {3 // Toggle p ins 6 and 12 o f port A and E r e s p e c t i v e l y4 HAL GPIO TogglePin (GPIOA, GPIO PIN 6 ) ;5 HAL Delay (100) ;6 HAL GPIO TogglePin (GPIOE, GPIO PIN 12 ) ;7 HAL Delay (100) ;8 }

Listing 6.4: Application code to toggle multiple pins of two different ports A and E

Test result: The test case is passed and the emulator successfully outputs toggling of the GPIOpins PA6 and PE12. The clock is successfully set to 16MHz. The output is listed in Listing C.4in Appendix.

Test case 4: A CPU operation to perform addition of two numbers and then toggle twoGPIO pins is added to increase the emulated CPU load while being functionally correct. Listing6.5 shows the application logic to toggle the GPIO pins of ports A and E with addition operation.

1 whi l e (1 )2 {3 f o r ( i =0; i <10; i++)4 {5 a=a+i ;6 i f ( a>5)7 { // t o g g l e i f a>58 HAL GPIO TogglePin (GPIOA, GPIO PIN 9 ) ;9 a=0;

1011 }12 HAL Delay (1000) ; // de lay13 }1415 HAL GPIO TogglePin (GPIOA, GPIO PIN 10 ) ;16 // a f t e r the f o r loop1718 }19 }

Listing 6.5: Application code to toggle multiple pins of two different ports A and E

Test result: The test case is passed and the emulator successfully performs addition andoutputs the GPIOA pin11 and Pin 13 when conditions are met. The output of the execution islisted in Listing C.5 in Appendix.

The functionality tests executed in this section provide an overview of the correctness of theprocessor, clock and GPIO configurations and their output. The output generation of an applic-ation logic can be tested in QEMU with an environment that mimics the real-time environment.



These tests also validate the faultlessness of the firmware implemented. Any fault in firmwareis tolerated by the emulated hardware similar to the physical hardware. A segmentation fault isgenerated if the stack, memory, handler definitions are misinterpreted by the emulated hardware.In SIL, the OS, CPU, ISA belong to the real hardware which is completely different from the real-time environment. Even though QEMU uses host hardware for the computations, the applicationlogic is still unaware of lower layers operations of QEMU. These propositions from QEMU makeit a suitable tool to carry out UT and IT in EDLC.

6.3 Scalability test

Scalability is the system attribute that addressed growth. It is the ability of a system to handle theincreased workload without adding additional resources to the system. As discussed in Chapter2, a minimum of 3-4 ECUs are involved in the sorting of a parcel at one out-feed in the sortersystems. The operations between the ECUs are sequential, which take input from preceding ECUand produce output for the next and finally to the end device. In most of the complex Embeddedsystems present in industrial automation and automotive technology the ECUs function in largersystems and perform various tasks sequentially or concurrently depending on the requirement.This associativity demands to have test setups with multiple instances of ECUs to perform atest of ESW acting on control variable values from other ECUs. The scalability is an attributemostly required in integration testing. Apart from having instances of QEMU, it is required tohave communication between these instances. The effect of running multiple instances of QEMUon the host machine with specifications discussed in the experimental setup is evaluated in thissection. Scaling on QEMU instances affects the CPU load and execution time. The effect ofscalability on timing performance is directly proportional to the CPU usage and it is discussed indetail in Section 6.4.

6.3.1 CPU Usage:

Scaling on the instances of QEMU affects the CPU of the host hardware. Currently, measurementswith QEMU are performed on a system with Ubuntu 16.04 OS and Intel i5 with 4 cores. On themulti-core systems, the percentages of CPU usage can be greater than 100%. In this context, theCPU usage is depicted as the accumulated load on 4 cores summing to 400% total load on thereal hardware. The CPU usage is derived from running the top command in the terminal. TheCPU usage can be analyzed in two different parameters; CPU share and CPU load. CPU shareis the averaged percentage of CPU capacity used by every QEMU instance. The CPU load is theaveraged total load exerted by the QEMU instances on the total CPU capacity.

A single instance of the QEMU takes up to 105.6% accumulated CPU share. The percentageremains the same for 3 QEMU instances running parallelly. Upon running the fourth instance,the CPU share assigned to the 4th instance decreases to around 90%. The bar graph in Figure 6.2represents the relation between the averaged percentage of CPU share with the number of QEMUinstances. The percentage of CPU share is indirectly proportional to the number of QEMUinstances. As the number of instances increases, the amount of CPU load increases, decreasingthe percentage of CPU share among the instances. The CPU load is depicted in Figure 6.3, wherethe load on the CPUs increases as the number of QEMU instances increases. The host machinetries to run the QEMU instances with an equal CPU share as seen in Figure 6.1. After 10 QEMUinstances, the CPU share becomes steady with around 30% of the CPU share for each instance ofQEMU.



Figure 6.1: Plot of number of QEMU instances v. the % of CPU share of one instance when 10instances are running parallelly.

Figure 6.2: Plot of number of QEMU instances v. the % of total CPU capacity shared amongQEMU instances



Figure 6.3: Plot of number of instances v. average CPU Load

As seen in Figure 6.3 the CPU load is shared between the four cores. This load on CPUdue to increasing instances greatly impacts the timing performance of the system. The timingperformance is analyzed in detail in Section 6.4. The measurements are made in an ideal conditionwhere there were no other programs running on the system. This infers that running multipleQEMU instances requires a powerful host hardware configuration. The scalability performanceis also sensitive to QEMU functionalities used, the QEMU monitor used to interact with QEMUalso brings down the performance of the instances by 10%. This can be avoided by adding the-nographic option to the QEMU invoking command as shown in Listing 5.3. Although runningmultiple instances may affect the timing performance, the logical correctness of the applicationlogic and the illusion real hardware for the application logic is maintained. The defects related tostack, memory, and firmware can still be caught during a unit or integration testing.

6.3.2 Memory Usage:

QEMU creates virtual pages that are mapped onto the physical memory of the host hardware.QEMU is run on a system with 4 Gigabytes(GB) RAM in total, where, 1 GB is used for cache.Total tasks run by 10 instances are 167 with 390 threads running on 4 cores. The virtual memorythat has been mapped onto guest memory for each of the instances is 527 Megabytes(MB) andphysical memory is the resident size which is the actual memory consumed by the instances. Thephysical memory is allocated around 31 MB for each instance when 10 instances are run togetherwhich sums up to 310MB of physical memory. This measurement remains the same even when10 instances are run together. This shows that the scaling on QEMU instances does not greatlyaffect the memory usage of the host hardware or QEMU performance.



6.4 Real-Time performance test

Adhering to deadlines is one of the very important performance metrics for embedded systems.Virtual machines work by timesharing host physical hardware due to which a virtual machine can-not exactly duplicate the timing behavior of a physical machine. The performance tests conductedin this section are carried out to analyze the timing accuracy achieved by QEMU.

The c codes used in Section 6.2 are utilized to perform the real-time tests. The timing perform-ance is measured for single a QEMU instance and for multiple instances with the same applicationlogic. A delay of 100ms is added between the toggling output as shown in Listing 6.2. The 100msdelay between each toggle is used as the parameter to measure the timing correctness. Approxim-ately 200 samples of output are collected to measure the timing irregularities. The 100ms delaycount between the GPIO toggling output is generated by virtual clock QEMU VIRTUAL CLOCKwhich is the simulated time. However, the timing performance is measured against the real-timeclock of the host machine. The 100ms delay by the virtual clock is compared to the real-timeclock QEMU CLOCK HOST. The real-time clock variable from the QEMU source code is tappedto extract the exact time at which the GPIO pin is toggled with respect to the real-time clock.The output of the real-time clock is shown in Appendix Listing C.1.

Another factor that should be considered while conducting the timing performance test is, thatthe underlying host OS is not real-time and is pre-emptive in nature. When multiple instancesof QEMU are run in parallel, the CPU share among the instances settles after 10 instances. TheCPU share remains around 40% on an average as shown in Figure 6.1. In such case, the instancesare scheduled in two modes Running (R) and Sleeping (S) for QEMU processes. When CPUshare cannot be minimized any further the CPU switches between ’R’ and ’S’ states of QEMUprocesses. Every instance is a process that starts its life in the R state. The OS then allows thegiven process to execute for a very small amount of time, and then it switches over to anotherprocess. This is how the host OS appears to be running multiple instances parallelly. Figure 6.4shows the different states of processes by Linux.

Figure 6.4: Different states of processes in Linux OS [33]

Instances are pushed to interrupt-able sleeping mode sequentially for a period of time andthen invoked again to run. When processes are scheduled this way, the timing performance of theinstances decreases. Not only does QEMU exceeds the 100ms in some cases but also producesoutput in some cases before 100ms. The minimum and maximum time taken between each GPIOtoggle can be seen in Figure 6.5. The y-axis depicts the averaged latency in milliseconds of eachtest run. The x-axis is the number of QEMU instances.



Figure 6.5: Plot of number of QEMU instances v. average latency with minimum and maximumvalues

Figure 6.6: Plot of number of QEMU instances v. average latency and average CPU load



The average latency between every toggle increases as the number of instances increases. Figure6.6 depicts a relative measure between the average latency and CPU load. The minimum andmaximum values of each test run remain stochastic due to the increased CPU load and OS processswitches. At instances 6 and 9, the minimum time between GPIO pin toggle is 99ms even withhigh CPU load. It should be noted that the latency in milliseconds is the measure of the hostclock. According to the simulated time, the output is still time accurate while relative to the hostclock, the time will vary due to scalability issues. Another test case is run to check idle processingtime. Two QEMU instances are invoked where instance 1 is waiting for the next instruction in aninfinite loop and instance 2 is toggling a pin on GPIO in an infinite loop. Even when the instance1 is idle, the scalability and timing performances are compromised.

To conclude, the timing performance of QEMU concerning the host machine is not real-timewhereas, with respect to the simulated virtual machine, the timing performance is accurate with1ms tolerance. The emulation is deterministic in the virtual environment and hence QEMU canstill be used to measure the timing performance if the virtual clock is measured and used tosynchronize with other virtual interfaces.

6.5 Other tests

Embedded systems must also exhibit extra-functional properties such as reliability and availability.Collectively reliability and availability account to lack dependability of the system on externalsupport for maintenance. Reliability is the Mean Time To Failure (MTTF) and availability isthe Mean Time Between Failure (MTBF). In this project context, the probability that a system,including all hardware, firmware, and software, will satisfactorily perform the task for which itwas designed or intended, for a specified time and in a specified environment is reliability andmean time between the failure to do so is the availability. It is verified so far that the emulatedhardware is reliable considering the logical correctness and modularity. QEMU is not well suitedfor timing tests unless if the QEMU performance is measured with simulated time and interfacesare synchronized on the simulated time. To test both reliability and availability, application logicto toggle in an infinite loop is run for three hours. It is observed that the system runs without anyfailures. The result remains the same even with multiple instances and multiple CPU operationsadhering to the simulated time. The evaluation can be verified better with complex ESW, addedperipherals and interfaces.


This chapter is intended to understand the performance of the emulated hardware concerningthe physical hardware. It is evident that the emulated hardware behavioral tests and functionaltests pass with output as expected. The scalability of the QEMU can be achieved as per therequirement of the test environment. The host machine must be competent to run the increasingnumber of instances. The number of processors of the host machine must be more than the numberof instances running on the guest machine to achieve considerable timing performance with respectto simulated time. QEMU can be best suited for unit testing with one QEMU instance and canbe used for integration testing if simulated time is measured for real-time behavior.


Chapter 7

Conclusions

In this thesis, an approach to introduce the emulated STM32 hardware controller on the hypervisorQEMU to the embedded test environments is considered. Initially, a literature study of the existingverification procedures used in the Embedded Development Life Cycle (EDLC) is carried out tocomprehend the demand for virtual hardware in the test cycle. In the initial study, embedded andreal-time requirements are extracted that have to be accomplished by the virtual platform after theemulation. Based on the initial requirements derived from the literature study, design requirementsfor the implementation of the emulation of the STM32F407 hardware controller are identified. Anemulator also known as the hypervisor is selected using preconditions acquired in the literaturestudy, design requirements and availability of STM32 support. To actualize the implementationof the emulation, the elemental peripherals of the hardware board STM32F407 are selected. Themeasurement and analysis of the emulated hardware are conducted after the implementation tounderstand the behavior of the emulated hardware for the real-time requirements derived in theliterature study. A detailed summary of the outcome of the thesis is presented in the next section.

7.1 Outcomes of the thesis

All the goals presented in Section 1.4 are correlated with the conclusions demonstrated in thissection. The objectives and goals set for this thesis implementation are achieved. The objectivesset for the thesis are in three folds literature study of the test environment in embedded systems,implementation of the emulation of the STM32 hardware board and the performance analysis ofthe emulated hardware. Additionally, detailed documentation of the QEMU study is presented.

A detailed study of generic test environments of embedded systems and test setup at Vander-lande is conducted in this thesis as a part of research question 1. This study of test environmentsin embedded systems is started with a known issue in EDLC that, the physical hardware such asan ECU is unavailable at the early stages of Unit Testing (UT) and Integration Testing (IT). Keep-ing this as the base problem, the literature study is carried out to understand the functionalitiessupplied by the real physical hardware in EDLC.

Both the study reveal a pattern of inconsistencies in the UT and IT. It is understood from thisstudy that the initial phases of the EDLC, architectural design and component design extensivelyuse MIL and SIL to visualize the SUT. The major inconsistencies found during this study existin the unit testing and integration testing due to the missing embedded requirements. Anotheroutcome of this study is the understanding of underlying embedded requirements that are missingin current embedded test environments and motivate the emulation. Due to the lack of embeddedand real-time hardware during UT and IT, the hardware-specific defects are not surfaced. Thisconclusion has been discussed in detail in Chapter 2 which includes differences between desktop PCon which UT and IT are run in reality and the target hardware. The GPOS, processor architectureof desktop PC, missing firmware requirement and simulated time in UT and IT are the reasonsfor the defect snowballing in the system test phase. Based on this conclusion motivation for the


CHAPTER 7. CONCLUSIONS

virtualization is obtained.The missing embedded requirements in UT and IT are the key findings for this thesis to study

virtualization and to concretely understand the expectations from virtualization in EDLC. A thor-ough study is performed on the virtualization in embedded systems and the types of virtualizationtechniques offered by this technology that fulfills the demands of UT and IT in EDLC. It is con-cluded from this study that, although virtualization satisfies most of the prerequisites of the UTand IT, the tool used to achieve virtualization, hypervisor, functions on a virtual clock. Thesimulated time is not deterministic due to the dependency on the underlying host machine. Acomplete study of virtualization and simulated time is performed in Chapter 3.

Based on the three secondary goals derived from the research question 2 as indicated in Section1.4, an emulator is chosen based on the design requirements indicated in Chapter 4. The require-ment of precise firmware as generated for real hardware by VM re-confirms that the firmware testcan be carried out using a hypervisor. Any errors in firmware will not run the developed binarymimicking the behavior of real hardware. Chapter 5 involves the development of the STM32F407vehardware controller with chosen peripherals processor Cortex M4, Clock control, memory, I/O andGPIO and it is successfully achieved. During the implementation of the STM32F407ve controller,a detailed study of QEMU and its workflow is conducted and documented in this report. TheSTM32 controller developed can be already used to verify firmware, identify processor relateddefects and functionality of RTSW that involves GPIO peripheral.

Concerning the execution of instructions by guest CPU, the Cortex-M4 processor in QEMUis not bound by the clock frequency configured by the binary. The CPU of QEMU runs as fastas it can to compensate for the dependency on the host hardware. Assigning clock frequency tothe processor can be inefficient as it may slow down the processor further. However, with respectto the guest’s behavior emulation, SYSCLK frequency still ensures that the complete system isexecuted with configured clock frequency by the firmware as discussed in Chapter 5.

Finally the chapter 6 explores in detail the research question 3. The measurement goals arederived from the requirements of both generic test setup in embedded systems and test setup atVanderlande. The outcome of the measurement analysis is in three folds:

i The behavioral analysis or functional test of the emulated hardware is identical to the realhardware except for the hardware configuration such as pull-up or pull-down configurationsof GPIO pin. The emulated hardware behavior in regards to the firmware for the bare-metal system, interrupt handling, CPU instruction handling agrees with the real hardwarebehavior. This analysis is described in detail in Chapter 5. The binary file is developed andtested successfully identical to the artifact developed for real hardware.

ii Timing performance of the emulated hardware is measured in two perspectives - Simulatedtime and Real-time as discussed in Chapter 3. The outcome of the thesis shows that whencompared to the real-time clock the virtual clock runs behind the real-time clock whichaffects the real-time testing in UT and IT. On the other hand, the simulated time remainstrue to the virtual clock running on time with a tolerance of 1ms. The real-time tests canbe still performed with respect to the simulated time.

iii The performance analysis of the QEMU concerning the scalability in Chapter 6 shows thatthe hypervisor is highly dependent on the host machine. The hypervisor is another applic-ation running on the resources of the host machine- GPOS and host hardware. Due to thehost machine’s tasks and processes, there are random pre-emptions in the QEMU execution.These irregular pre-emptions are observed mostly when the number of QEMU instances in-crease. This shows that depending on the complexity of the SUT, the configuration of thedesktop PC must be adjusted. To run a minimum of 4 instances of QEMU 5 CPU cores inthe host machine is recommended.

Another interesting inference made during the performance analysis of the emulated hard-ware is that as the scalability increases, the percentage of CPU share between the QEMUinstances decreases. Even though the CPU share decreases, it does not decrease randomly



between the instances. The CPU share between the instances is almost evenly distributed.Due to this even distribution, the simulated time remains the same among all the instances.This balanced CPU share facilitates time-synchronization between the instances for inter-facing. However, it is observed that the host OS handles every instance of QEMU dividedbetween multiple threads when the number of instances increase more than the number ofcores in the host machine. During such execution, one instance of QEMU may advance inits simulated time compared to other instances. For instance, for a time resolution of 1 ms,where 1 QEMU instance is able to advance 2 ms, while another instance is unable to advanceat the same time. To force the synchronization of all QEMU instances, a barrier synchron-ization might be required. In such cases, synchronization of instances based on simulatedtime can be handled by restricting every instance to advance together in simulated time.

7.1.1 Recommendations to use emulated hardware boards on hyper-visors

1. For unit testing, additional peripherals and their registers must be suppressed using QEMUlogging functionalities as discussed in Chapter 6.

2. QEMU is highly recommended for UT as the CPU load is low and timing performance isbetter.

3. In case of IT, the firmware validation and other CPU architecture-specific, stack and memory-related defects can still be captured. Functional tests can be run for data flow and controlflow validations of ESW.

4. IT can be still executed on QEMU with respect to timing performance, if the number ofCPUs on the host machine is more than the number of the QEMU instances running on thehypervisors and the time measured is in simulated time.

5. Interfacing with other external virtualization and QEMU instances can be achieved byQEMU’s network interface functionalities and synchronizing on the simulated time.

7.2 Future work

The thesis provides multiple pathways to expand virtualization into embedded systems testing.Below are some of the aspects that should be considered to widen this thesis.

1. Complete implementation of STM32 hardware: The RTSW tested on the emulatedhardware was only configured for GPIO in this thesis. To test the complete RTSW thatgoes into the production and determine the load on the QEMU instance, STM32 must beimplemented with all the peripherals such as Ethernet, CAN, UART, etc starting with theextensively used peripheral. By testing the actual RTSW on the complete STM32 emulatedhardware, actual readings of CPU load, % CPU share, real-time performance, scalabilitycan be visualized.

2. Improvements in QEMU clock: It is understood from the QEMU implementation that,by default, QEMU CPUs run as fast as possible and the frequency provided by the binary filedoes not affect the Cortex-M4 CPU of STM32. An attempt to run cycle-accurate, tightly-timed processor emulation without affecting the instruction-execution rate must be madeto make QEMU more real-time. This can be achieved by understanding QEMU workflowin-depth and edit the source code of QEMU to execute the instructions at a certain clockfrequency.

3. QEMU instances Interface: Interactions between the multiple QEMU instances canbe taken forward to achieve complete virtualized test setup to realize the behind the desktesting. QEMU does provide a network interface functionality to connect to other devices.



Moving forward this functionality can be used to interact with other devices in the testsetup.

4. KQEMU/ KVM Optimization: Virtualization has had immense growth due to theadvent of the x86 processor-based computer architectures. Recent work shows Linux providesKernel-Based Virtual Machines(KVM) to support the virtualization of x86 based processorhardware boards. In cases where the host CPU and guest CPU architecture is the same, forexample, both the host and guest have x86-64 architecture KQEMU /KVM can be utilizedto accelerate the QEMU performance. Both the optimizations execute the CPU instructionsunchanged from the host machine accelerating QEMU performance.


Bibliography

[1] The role of virtualization in embedded systems, 04 2008. https://www.researchgate.net/

publication/234804454_The_role_of_virtualization_in_embedded_systems. iii

[2] Luiz Capitulino Anthony Liguori. Qmp: Initial support. https://github.com/qemu/qemu/

commit/9b57c02e3e14163b576ada77ddd1d7b346a6e421. 42

[3] ARM. Elf for the arm architecture. Technical report, ARM, 2015. http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf. 36

[4] ARM. Fixed virtual platforms. Technical report, ARM, 2015. https://static.docs.arm.

com/dui0837/e/DUI0837E_fast_models_fvp_rg.pdf. 29

[5] ARM. Virtual targets for arm-based socs and subsystems, 2015. https://nl.mathworks.

com/products/connections/product_detail/arm-fast-models.html. 29

[6] Balau. Simplest bare metal program for arm, 2010. https://balau82.wordpress.com/

2010/02/28/hello-world-for-bare-metal-arm-using-qemu/. 38

[7] Richard Barry. Mastering the freertos real time kernel. Technical report, freertos.org,2016. https://freertos.org/Documentation/161204_Mastering_the_FreeRTOS_Real_

Time_Kernel-A_Hands-On_Tutorial_Guide.pdf. 35

[8] Andre Beckus. Stm32p103 development of pebble board. https://github.com/beckus/

qemu_stm32. 42

[9] Fabrice Bellard. Qemu, a fast and portable dynamic translator. Technical report,QEMU, 2005. http://static.usenix.org/event/usenix05/tech/freenix/full_papers/bellard/bellard.pdf. iii, 30

[10] Jacob Beningo. Rtos or bare metal - five decisive factors, 2015. https://freertos.

org/Documentation/161204_Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_

Tutorial_Guide.pdf. 35, 36

[11] Ian Mc Gregor Bernard Brooks, Adam Davidson. The evolving relationship between simula-tion and emulation: Faster than real-time controls testing. Semanticscholar, 2014. https:

//pdfs.semanticscholar.org/1799/125db9c5d93def993617e7f20be8c2b56cbd.pdf. 21

[12] Emily Blem, Jaikrishnan Menon, and Karthikeyan Sankaralingam. A detailed analysisof contemporary arm and x86 architectures. semanticscholar, 01 2013. https://pdfs.

semanticscholar.org/a694/f3583ca033904d9d3073d3693feac585a2bb.pdf. ix, 18

[13] Alex Bligh. Changes to qemu’s timer system. Technical report, Alex Bligh’Blogs, 2013.http://blog.alex.org.uk/2013/08/24/changes-to-qemus-timer-system/. ix, 49

[14] Dr.Reinder J Bril. Real-time systems (2imn20). Technical report, TU/e Informatica, Sys-tem Architecture and Networking, 2019. https://www.win.tue.nl/~rbril/education/

2IMN20/. ix, 10


https://www.researchgate.net/publication/234804454_The_role_of_virtualization_in_embedded_systems

https://www.researchgate.net/publication/234804454_The_role_of_virtualization_in_embedded_systems

https://github.com/qemu/qemu/commit/9b57c02e3e14163b576ada77ddd1d7b346a6e421

https://github.com/qemu/qemu/commit/9b57c02e3e14163b576ada77ddd1d7b346a6e421

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf

https://static.docs.arm.com/dui0837/e/DUI0837E_fast_models_fvp_rg.pdf

https://static.docs.arm.com/dui0837/e/DUI0837E_fast_models_fvp_rg.pdf

https://nl.mathworks.com/products/connections/product_detail/arm-fast-models.html

https://nl.mathworks.com/products/connections/product_detail/arm-fast-models.html

https://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/

https://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/

https://freertos.org/Documentation/161204_Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_Tutorial_Guide.pdf


https://github.com/beckus/qemu_stm32

https://github.com/beckus/qemu_stm32

http://static.usenix.org/event/usenix05/tech/freenix/full_papers/bellard/bellard.pdf





https://pdfs.semanticscholar.org/1799/125db9c5d93def993617e7f20be8c2b56cbd.pdf

https://pdfs.semanticscholar.org/1799/125db9c5d93def993617e7f20be8c2b56cbd.pdf

https://pdfs.semanticscholar.org/a694/f3583ca033904d9d3073d3693feac585a2bb.pdf

https://pdfs.semanticscholar.org/a694/f3583ca033904d9d3073d3693feac585a2bb.pdf

http://blog.alex.org.uk/2013/08/24/changes-to-qemus-timer-system/

https://www.win.tue.nl/~rbril/education/2IMN20/

https://www.win.tue.nl/~rbril/education/2IMN20/

BIBLIOGRAPHY

[15] Khansa Butt, Abdul Qadeer, and Abdul Waheed. Mips64 user mode emu-lation: A case study in open source software engineering. researchgate, 092011. https://www.researchgate.net/publication/252053314_MIPS64_user_mode_

emulation_A_case_study_in_open_source_software_engineering. 24

[16] Ghizlane Tibba ; Christoph Malz ; Christoph Stoermer ; Natarajan Nagarajan ; LicongZhang ; Samarjit Chakraborty. Testing automotive embedded systems under x-in-the-loopsetups. In Invited Papaer, 2016. https://ieeexplore-ieee-org.dianus.libr.tue.nl/

stamp/stamp.jsp?tp=&arnumber=7827612&tag=1/. 11

[17] Youssef Cheddadi, Fatima Errahimi, and Najia Es-sbai. Design and verification of photo-voltaic mppt algorithm as an automotive-based embedded software. Solar Energy, 171:414– 425, 2018. http://www.sciencedirect.com/science/article/pii/S0038092X18306364.11

[18] Sawomir Chyek. Emulation based software reliability evaluation and optimization. 2014, url =https://pdfs.semanticscholar.org/9e12/fad8cf6e1c7eb4fea5620e8398d4bfbda540.pdf, note =”https://pdfs.semanticscholar.org/9e12/fad8cf6e1c7eb4fea5620e8398d4bfbda540.pdf”. 57

[19] Doulos. Getting started with cmsis. Technical report, www.Doulos.com, 2009. https:

//www.doulos.com/knowhow/arm/CMSIS/CMSIS_Doulos_Tutorial.pdf. ix, 16

[20] Prabal Dutta. Design of microprocessor-based systems. Technical report, University ofMichigan, 2012. https://web.eecs.umich.edu/~prabal/teaching/resources/eecs373/

toolchain-notes.pdf. ix, 34, 36

[21] Alister Francis. Stm32f205 development. https://github.com/qemu/qemu. 42

[22] Anthony Liguori Gerd Hoffmann. Qemuopts: framework for storing and parsing options.https://github.com/qemu/qemu/commit/e27c88fe9eb26648e4fb282cb3761c41f06ff18a.42

[23] R. Goldstein, S. Breslav, and A. Khan. A quantum of continuous simulated time.In 2016 Symposium on Theory of Modeling and Simulation (TMS-DEVS), pages 1–8, April 2016. https://www.researchgate.net/publication/310794910_A_Quantum_of_

Continuous_Simulated_Time. 24, 25

[24] Eduardo Habkost. habkost.net. Technical report, [Qemu-devel] documentation on qemu,2016. https://habkost.net/posts/2016/11/incomplete-list-of-qemu-apis.html. 42

[25] Ravi Nair James E. Smith. The architecture of virtual machines. Technical report, Universityof Wisconsin-Madison,IBM T.J. Watson Research Center, 2005. https://www.csd.uoc.gr/

~hy428/reading/smith_nair_2005.pdf. 21, 24

[26] Granberg Opsahl Jan Magnus. Open-source virtualization functionality and performance ofqemu/kvm, xen, libvirt and virtualbox. Master’s thesis, UNIVERSITY OF OSLO, 03 2013.https://www.duo.uio.no/handle/10852/37427. 23

[27] M. Tim Jones. System emulation with qemu. Semanticscholar, 2007. https://pdfs.

semanticscholar.org/ae16/189e3b79b3c8dd09bad76ed076b02cf55319.pdf. 30

[28] Andreas Junghanns. Virtual integration of automotive hard- and software with silver. Tech-nical report, qtronics, 2014. http://static.usenix.org/event/usenix05/tech/freenix/

full_papers/bellard/bellard.pdf. 30

[29] John Kneen. Microcontroller-clock: Stm32f407. Technical report, RMIT University, 2013.https://sites.google.com/site/johnkneenmicrocontrollers/clocks/clk407. ix, 47


https://www.researchgate.net/publication/252053314_MIPS64_user_mode_emulation_A_case_study_in_open_source_software_engineering

https://www.researchgate.net/publication/252053314_MIPS64_user_mode_emulation_A_case_study_in_open_source_software_engineering

https://ieeexplore-ieee-org.dianus.libr.tue.nl/stamp/stamp.jsp?tp=&arnumber=7827612&tag=1/

https://ieeexplore-ieee-org.dianus.libr.tue.nl/stamp/stamp.jsp?tp=&arnumber=7827612&tag=1/

http://www.sciencedirect.com/science/article/pii/S0038092X18306364

https://pdfs.semanticscholar.org/9e12/fad8cf6e1c7eb4fea5620e8398d4bfbda540.pdf

https://pdfs.semanticscholar.org/9e12/fad8cf6e1c7eb4fea5620e8398d4bfbda540.pdf

https://www.doulos.com/knowhow/arm/CMSIS/CMSIS_Doulos_Tutorial.pdf

https://www.doulos.com/knowhow/arm/CMSIS/CMSIS_Doulos_Tutorial.pdf

https://web.eecs.umich.edu/~prabal/teaching/resources/eecs373/toolchain-notes.pdf

https://web.eecs.umich.edu/~prabal/teaching/resources/eecs373/toolchain-notes.pdf

https://github.com/qemu/qemu

https://github.com/qemu/qemu/commit/e27c88fe9eb26648e4fb282cb3761c41f06ff18a

https://www.researchgate.net/publication/310794910_A_Quantum_of_Continuous_Simulated_Time

https://www.researchgate.net/publication/310794910_A_Quantum_of_Continuous_Simulated_Time

https://habkost.net/posts/2016/11/incomplete-list-of-qemu-apis.html

https://www.csd.uoc.gr/~hy428/reading/smith_nair_2005.pdf

https://www.csd.uoc.gr/~hy428/reading/smith_nair_2005.pdf

https://www.duo.uio.no/handle/10852/37427

https://pdfs.semanticscholar.org/ae16/189e3b79b3c8dd09bad76ed076b02cf55319.pdf

https://pdfs.semanticscholar.org/ae16/189e3b79b3c8dd09bad76ed076b02cf55319.pdf



https://sites.google.com/site/johnkneenmicrocontrollers/clocks/clk407

BIBLIOGRAPHY

[30] Juho Lepist. Embedded software testing methods. Master’s thesis, Helsinki Metropolia Uni-versity of Applied Sciences, 03 2012. https://core.ac.uk/download/pdf/38063214.pdf.1

[31] Grischa Liebel, Nadja Marko, Matthias Tichy, Andrea Leitner, and Jorgen Hansson. Model-based engineering in the embedded systems domain: an industrial survey on the state-of-practice. Software & Systems Modeling, 17(1):91–113, Feb 2018. https://doi.org/10.

1007/s10270-016-0523-3. 1

[32] Anthony Liguori. qom: add the base object class(v2). https://github.com/qemu/qemu/

commit/2f28d2ff9dce3c404b36e90e64541a4d48daf0ca. 42

[33] Marek. Linux process states. https://idea.popcount.org/

2012-12-11-linux-process-states/. ix, 64

[34] D. Mathew and B. A. Jose. Performance analysis of virtualized embedded computing systems.In 2017 7th International Symposium on Embedded Computing and System Design (ISED),pages 1–5, Dec 2017. https://ieeexplore-ieee-org.dianus.libr.tue.nl/document/

8303932. 57

[35] Jakob Mauss Mugur Tatar. Systematic test and validation of complex embedded systems.Technical report, qtronics, 2014. https://www.qtronic.de/doc/ERTS_2014_TestWeaver_

Paper.pdf. 30, 31

[36] Ralf Garrelfs Narayanamurthy Srinivas, Narendrakumar Panditi Stefan Schmidt.Mil/sil/pil approach a new paradigm in model based development. Tech-nical report, Mathworks, 2014. https://www.mathworks.com/content/dam/

mathworks/mathworks-dot-com/solutions/automotive/files/in-expo-2014/

mil-sil-pil-a-new-paradigm-in-model-based-development.pdf/. 12

[37] Jonathan Nibert, Marc Herniter, and Zachariah Chambers. Model-based system design formil, sil, and hil. World Electric Vehicle Journal, 5(4):11211130, Dec 2012. http://dx.doi.

org/10.3390/wevj5041121. 12

[38] Jerry Banks; John S. Carson; Barry L. Nelson; David M. Nicol. Discrete-Event Sys-tem Simulation (3rd Edition). Prentice Hall, August 2000. https://www.abebooks.com/

9780130887023/Discrete-Event-System-Simulation-3rd-Edition-0130887021/plp. 10

[39] Daniel O’Hara. Debugging embedded systems part 2: Fault hand-ling and diagnosis. Technical report, arm community, 2016. https://

community.arm.com/developer/ip-products/system/b/embedded-blog/posts/

debugging-embedded-systems-part-2-fault-handling-and-diagnosis. 18

[40] OVP. Virtual platforms - the source of fast processor models & platforms, 2008-2019. http://www.ovpworld.org/technology#sectionOSM. iii, 29

[41] Rachana Rao Pradyumna Sampath. Efficient embedded software development using qemu.Technical report, ABB Corporate Research, 2014. https://static.lwn.net/images/conf/rtlws11/papers/proc/p09.pdf. 9, 10, 21

[42] QEMU. Qemu download page for linux. https://github.com/qemu/qemu. 34, 39

[43] QEMU. Qemu download page for windows. https://github.com/qemu/qemu. 34

[44] Renjith Ravindran. Qemu detailed study. Technical report, [Qemu-devel] documentationon qemu, 2011. https://lists.gnu.org/archive/html/qemu-devel/2011-04/msg02362.

html. ix, ix, 39, 40, 41


https://core.ac.uk/download/pdf/38063214.pdf

https://doi.org/10.1007/s10270-016-0523-3

https://doi.org/10.1007/s10270-016-0523-3

https://github.com/qemu/qemu/commit/2f28d2ff9dce3c404b36e90e64541a4d48daf0ca

https://github.com/qemu/qemu/commit/2f28d2ff9dce3c404b36e90e64541a4d48daf0ca

https://idea.popcount.org/2012-12-11-linux-process-states/

https://idea.popcount.org/2012-12-11-linux-process-states/

https://ieeexplore-ieee-org.dianus.libr.tue.nl/document/8303932

https://ieeexplore-ieee-org.dianus.libr.tue.nl/document/8303932

https://www.qtronic.de/doc/ERTS_2014_TestWeaver_Paper.pdf

https://www.qtronic.de/doc/ERTS_2014_TestWeaver_Paper.pdf

https://www.mathworks.com/content/dam/mathworks/mathworks-dot-com/solutions/automotive/files/in-expo-2014/mil-sil-pil-a-new-paradigm-in-model-based-development.pdf/



http://dx.doi.org/10.3390/wevj5041121

http://dx.doi.org/10.3390/wevj5041121

https://www.abebooks.com/9780130887023/Discrete-Event-System-Simulation-3rd-Edition-0130887021/plp

https://www.abebooks.com/9780130887023/Discrete-Event-System-Simulation-3rd-Edition-0130887021/plp

https://community.arm.com/developer/ip-products/system/b/embedded-blog/posts/debugging-embedded-systems-part-2-fault-handling-and-diagnosis



http://www.ovpworld.org/technology#sectionOSM

http://www.ovpworld.org/technology#sectionOSM

https://static.lwn.net/images/conf/rtlws11/papers/proc/p09.pdf

https://static.lwn.net/images/conf/rtlws11/papers/proc/p09.pdf



https://lists.gnu.org/archive/html/qemu-devel/2011-04/msg02362.html

https://lists.gnu.org/archive/html/qemu-devel/2011-04/msg02362.html

BIBLIOGRAPHY

[45] Victor Reyes. Virtual hardware in-the-loop: Earlier testing for automotive applications.Technical report, Synopsys, 2014. https://www.synopsys.com/cgi-bin/proto/pdfdla/

docsdl/virtual_hardware_wp.pdf?file=virtual_hardware_wp.pdf/. 12

[46] Sanket. Exponential cost of fixing bugs, January 2019. https://deepsource.io/blog/

exponential-cost-of-fixing-bugs/. ix, 3

[47] Martin Schroder. Stm32 development of discovery board. https://github.com/

mkschreder?utf8=%E2%9C%93&tab=repositories&q=qemu&type=&language=. 42

[48] CURT SCHWADERER. Embedded virtualization: Latest trendsand techniques. Technical report, Embedded Computing, 2014.https://www.embedded-computing.com/embedded-computing-design/

embedded-virtualization-latest-trends-and-techniques. 21

[49] Adam Dalentoft Simon Wallstrm. Emulation-based software development for embedded sys-tems. Master’s thesis, LUND University, 2016. http://lup.lub.lu.se/luur/download?

func=downloadFile&recordOId=8883882&fileOId=8883919. 22, 23, 30, 31

[50] SPEEDGOAT. Simulink real-time workflow. https://www.speedgoat.com/

learn-support/simulink-real-time-workflow. ix, 27

[51] STMicroelectronics. Description of STM32F4 HAL and LL drivers. https:

//www.st.com/content/ccc/resource/technical/document/user_manual/2f/71/ba/

b8/75/54/47/cf/DM00105879.pdf/files/DM00105879.pdf/jcr:content/translations/

en.DM00105879.pdf. 16

[52] STMicroelectronics. RM0090 Reference manual. https://www.st.com/content/

ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/

DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.

pdf. ix, ix, ix, x, x, x, x, x, x, x, x, x, xiii, 33, 34, 36, 37, 45, 46, 50, 78, 79, 80, 81, 82, 83, 84

[53] Warren Toomey. User- and kernel mode, system calls, i/o, exceptions. https://minnie.

tuhs.org/CompArch/Lectures/week05.html. 23

[54] VMWare. Timekeeping in vmware virtual machines. Technical report, VMWare, 2016. https://www.vmware.com/pdf/vmware_timekeeping.pdf. 25

[55] WA&S. What is an rtos? https://www.highintegritysystems.com/rtos/

what-is-an-rtos/. 17


https://www.synopsys.com/cgi-bin/proto/pdfdla/docsdl/virtual_hardware_wp.pdf?file=virtual_hardware_wp.pdf/

https://www.synopsys.com/cgi-bin/proto/pdfdla/docsdl/virtual_hardware_wp.pdf?file=virtual_hardware_wp.pdf/

https://deepsource.io/blog/exponential-cost-of-fixing-bugs/

https://deepsource.io/blog/exponential-cost-of-fixing-bugs/

https://github.com/mkschreder?utf8=%E2%9C%93&tab=repositories&q=qemu&type=&language=

https://github.com/mkschreder?utf8=%E2%9C%93&tab=repositories&q=qemu&type=&language=

https://www.embedded-computing.com/embedded-computing-design/embedded-virtualization-latest-trends-and-techniques

https://www.embedded-computing.com/embedded-computing-design/embedded-virtualization-latest-trends-and-techniques

http://lup.lub.lu.se/luur/download?func=downloadFile&recordOId=8883882&fileOId=8883919

http://lup.lub.lu.se/luur/download?func=downloadFile&recordOId=8883882&fileOId=8883919

https://www.speedgoat.com/learn-support/simulink-real-time-workflow

https://www.speedgoat.com/learn-support/simulink-real-time-workflow

https://www.st.com/content/ccc/resource/technical/document/user_manual/2f/71/ba/b8/75/54/47/cf/DM00105879.pdf/files/DM00105879.pdf/jcr:content/translations/en.DM00105879.pdf




https://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf




https://minnie.tuhs.org/CompArch/Lectures/week05.html

https://minnie.tuhs.org/CompArch/Lectures/week05.html

https://www.vmware.com/pdf/vmware_timekeeping.pdf

https://www.vmware.com/pdf/vmware_timekeeping.pdf

https://www.highintegritysystems.com/rtos/what-is-an-rtos/

https://www.highintegritysystems.com/rtos/what-is-an-rtos/

Appendix A

Development in QEMU

A.1 QEMU Machine list

123 sups@sups−Insp i ron −3421:˜/Documents/stm32/qemu$4 qemu−system−arm −machine help56 Supported machines are :7 ak i t a Sharp SL−C1000 ( Akita ) PDA (PXA270)8 ast2500−evb Aspeed AST2500 EVB (ARM1176)9 borzo i Sharp SL−C3100 ( Borzoi ) PDA (PXA270)

10 canon−a1100 Canon PowerShot A1100 IS11 cheetah Palm Tungsten |E aka . Cheetah PDA (OMAP310)12 c o l l i e Sharp SL−5500 ( C o l l i e ) PDA (SA−1110)13 connex Gumstix Connex (PXA255)14 cubieboard cub i e t ech cubieboard15 emcraft−s f 2 SmartFusion2 SOM k i t from Emcraft (M2S010)16 highbank Calxeda Highbank (ECX−1000)17 imx25−pdk ARM i .MX25 PDK board (ARM926)18 i n t e g r a t o r c p ARM I n t e g r a t o r /CP (ARM926EJ−S)19 kzm ARM KZM Emulation Baseboard (ARM1136)20 lm3s6965evb S t e l l a r i s LM3S6965EVB21 lm3s811evb S t e l l a r i s LM3S811EVB22 mainstone Mainstone I I (PXA27x)23 mcimx6ul−evk F r e e s c a l e i .MX6UL Evaluat ion Kit ( Cortex A7)24 mcimx7d−sabre F r e e s c a l e i .MX7 DUAL SABRE ( Cortex A7)25 midway Calxeda Midway (ECX−2000)26 mps2−an385 ARM MPS2 with AN385 FPGA image f o r Cortex−M327 mps2−an505 ARM MPS2 with AN505 FPGA image f o r Cortex−M3328 mps2−an511 ARM MPS2 with AN511 Des ignStart FPGA image f o r Cortex−M329 musicpal Marvel l 88w8618 / MusicPal (ARM926EJ−S)30 n800 Nokia N800 t a b l e t aka . RX−34 (OMAP2420)31 n810 Nokia N810 t a b l e t aka . RX−44 (OMAP2420)32 netduino2 Netduino 2 Machine33 none empty machine34 nur i Samsung NURI board ( Exynos4210 )35 palmetto−bmc OpenPOWER Palmetto BMC (ARM926EJ−S)36 r a s p i 2 Raspberry Pi 237 rea lv i ew−eb ARM RealView Emulation Baseboard (ARM926EJ−S)38 rea lv i ew−eb−mpcore ARM RealView Emulation Baseboard (ARM11MPCore)39 rea lv i ew−pb−a8 ARM RealView Platform Baseboard f o r Cortex−A840 rea lv iew−pbx−a9 ARM RealView Platform Baseboard Explore f o r Cortex−A941 romulus−bmc OpenPOWER Romulus BMC (ARM1176)42 s a b r e l i t e F r e e s c a l e i .MX6 Quad SABRE Li t e Board ( Cortex A9)43 smdkc210 Samsung SMDKC210 board ( Exynos4210 )44 s p i t z Sharp SL−C3000 ( Sp i t z ) PDA (PXA270)45 // stm32f407ve scu STM32F407 board with cortex−m446 sx1 Siemens SX1 (OMAP310) V2


APPENDIX A. DEVELOPMENT IN QEMU

47 sx1−v1 Siemens SX1 (OMAP310) V148 t e r r i e r Sharp SL−C3200 ( T e r r i e r ) PDA (PXA270)49 tosa Sharp SL−6000 ( Tosa ) PDA (PXA255)50 verdex Gumstix Verdex (PXA270)51 v e r s a t i l e a b ARM V e r s a t i l e /AB (ARM926EJ−S)52 v e r s a t i l e p b ARM V e r s a t i l e /PB (ARM926EJ−S)53 vexpress−a15 ARM V e r s a t i l e Express f o r Cortex−A1554 vexpress−a9 ARM V e r s a t i l e Express f o r Cortex−A955 v i r t −2.10 QEMU 2.10 ARM Vir tua l Machine56 v i r t −2.11 QEMU 2.11 ARM Vir tua l Machine57 v i r t −2.12 QEMU 2.12 ARM Vir tua l Machine58 v i r t −2.6 QEMU 2.6 ARM Vir tua l Machine59 v i r t −2.7 QEMU 2.7 ARM Vir tua l Machine60 v i r t −2.8 QEMU 2.8 ARM Vir tua l Machine61 v i r t −2.9 QEMU 2.9 ARM Vir tua l Machine62 v i r t QEMU 3.0 ARM Vir tua l Machine ( a l i a s o f v i r t −3.0)63 v i r t −3.0 QEMU 3.0 ARM Vir tua l Machine64 witherspoon−bmc OpenPOWER Witherspoon BMC (ARM1176)65 x i l i n x−zynq−a9 Xi l i nx Zynq Platform Baseboard f o r Cortex−A966 z2 Z i p i t Z2 (PXA27x)

Listing A.1: QEMU Machine list under ARM architecture along with newly added STM32 machine

A.2 Binary file Development

Figure A.1: Vector table in elf


APPENDIX A. DEVELOPMENT IN QEMU

Figure A.2: Memory layout in elf


Appendix B

Implementation of the STM32hardware

B.1 Reset and Clock control Register map

Figure B.1: RCC register map and reset values [52]


APPENDIX B. IMPLEMENTATION OF THE STM32 HARDWARE

Figure B.2: RCC register map and reset values contd. [52]



Figure B.3: Register RCC CR with definition of each bit [52]

Figure B.4: Register RCC CFGR with definition of each bit [52]

Figure B.5: STM32F407 AHB1 high speed bus clock enable register (RCC AHB1ENR) [52]

1 //RCC c lock c o n t r o l r e g i s t e r (RCC CR)2 #d e f i n e RCC CR RESET VALUE 0x000000833 #d e f i n e RCC CR OFFSET 0x004 #d e f i n e RCC CR PLLI2SRDY BIT 275 #d e f i n e RCC CR PLLI2SON BIT 266 #d e f i n e RCC CR PLLRDY BIT 257 #d e f i n e RCC CR PLLON BIT 248 #d e f i n e RCC CR CSSON BIT 199 #d e f i n e RCC CR HSEBYP BIT 18

10 #d e f i n e RCC CR HSERDY BIT 1711 #d e f i n e RCC CR HSEON BIT 1612 #d e f i n e RCC CR HSICAL START 813 #d e f i n e RCC CR HSICAL MASK 0 x0000 f f0014 #d e f i n e RCC CR HSITRIM START 315 #d e f i n e RCC CR HSITRIM MASK 0 x000000f816 #d e f i n e RCC CR HSIRDY BIT 117 #d e f i n e RCC CR HSION BIT 0181920 //RCC c lock c o n f i g u r a t i o n r e g i s t e r (RCC CFGR)21 #d e f i n e RCC CFGR RESET VALUE 0x0000000022 #d e f i n e RCC CFGR OFFSET 0x0823 #d e f i n e RCC CFGR MCO2 START 3024 #d e f i n e RCC CFGR MCO2 MASK 0xC000000025 #d e f i n e RCC CFGR MCO2PRE START 2726 #d e f i n e RCC CFGR MCO2PRE MASK 0x3800000027 #d e f i n e RCC CFGR MCO1PRE START 2428 #d e f i n e RCC CFGR MCO1PRE MASK 0x0700000029 #d e f i n e RCC CFGR I2SSRC BIT 2330 #d e f i n e RCC CFGR MCO1 START 21



31 #d e f i n e RCC CFGR MCO1 MASK 0x0060000032 #d e f i n e RCC CFGR RTCPRE START 1633 #d e f i n e RCC CFGR RTCPRE MASK 0x001F000034 #d e f i n e RCC CFGR PPRE2 START 1335 #d e f i n e RCC CFGR PPRE2 MASK 0x0000E00036 #d e f i n e RCC CFGR PPRE1 START 1037 #d e f i n e RCC CFGR PPRE1 MASK 0x00001C0038 #d e f i n e RCC CFGR HPRE START 439 #d e f i n e RCC CFGR HPRE MASK 0x000000F040 #d e f i n e RCC CFGR SWS START 241 #d e f i n e RCC CFGR SWS MASK 0x0000000C42 #d e f i n e RCC CFGR SW START 043 #d e f i n e RCC CFGR SW MASK 0x000000034445 //RCC AHB1 p e r i p h e r a l c l o ck enable r e g i s t e r (RCC AHB1ENR)46 #d e f i n e RCC AHB1ENR RESET VALUE 0x0010000047 #d e f i n e RCC AHB1ENR OFFSET 0x3048 #d e f i n e RCC AHB1ENR OTGHSULPIEN BIT 3049 #d e f i n e RCC AHB1ENR OTGHSEN BIT 2950 #d e f i n e RCC AHB1ENR ETHMACPTPEN BIT 2851 #d e f i n e RCC AHB1ENR ETHMACRXEN BIT 2752 #d e f i n e RCC AHB1ENR ETHMACTXEN BIT 2653 #d e f i n e RCC AHB1ENR ETHMACEN BIT 2554 #d e f i n e RCC AHB1ENR DMA2EN BIT 2255 #d e f i n e RCC AHB1ENR DMA1EN BIT 2156 #d e f i n e RCC AHB1ENR CCMDATARAMEN BIT 2057 #d e f i n e RCC AHB1ENR BKPSRAMEN BIT 1858 #d e f i n e RCC AHB1ENR CRCEN BIT 1259 #d e f i n e RCC AHB1ENR GPIOIEN BIT 860 #d e f i n e RCC AHB1ENR GPIOHEN BIT 761 #d e f i n e RCC AHB1ENR GPIOGEN BIT 662 #d e f i n e RCC AHB1ENR GPIOFEN BIT 563 #d e f i n e RCC AHB1ENR GPIOEEN BIT 464 #d e f i n e RCC AHB1ENR GPIODEN BIT 365 #d e f i n e RCC AHB1ENR GPIOCEN BIT 266 #d e f i n e RCC AHB1ENR GPIOBEN BIT 167 #d e f i n e RCC AHB1ENR GPIOAEN BIT 0

Listing B.1: Definition of RCC CR,RCC CFGR and RCC AHB1ENR in stm32f407xx rcc.c [52]

B.2 GPIO register map with reset values



Figure B.6: GPIO register map with reset values [52]



Figure B.7: GPIO register map with reset values contd. [52]



Figure B.8: Moder Register of STM32F407 [52]

Figure B.9: IDR Register of STM32F407 [52]

Figure B.10: ODR Register of STM32F407 [52]

B.3 Implementation of Clock Control

12 s t a t i c void c l k t r e e r e c a l c o u t p u t f r e q ( Clk c l k ) {3 i n t i ;4 Clk next c lk , n e x t c l k i n p u t ;5 u i n t 3 2 t new output f req ;67 /∗ Get the output frequency , or 0 i f the output i s d i s ab l ed . ∗/8 new output f req = clk−>enabled ?9 muldiv64 ( c lk−>i npu t f r eq ,

10 clk−>m u l t i p l i e r ,11 c lk−>d i v i s o r )12 : 0 ;13



14 /∗ i f the f requency has changed . ∗/15 i f ( new output f req != clk−>output f r eq ) {16 clk−>output f r eq = new output f req ;1718 #i f d e f DEBUG CLKTREE19 c l k t r e e p r i n t s t a t e ( c l k ) ;20 #e n d i f2122 /∗ Check the new frequency aga in s t the max frequency . ∗/23 i f ( new output f req > c lk−>max output freq ) {24 f p r i n t f ( s tde r r , ”%s : Clock %s output f requency (%d Hz) exceeds max

frequency (%d Hz) .\n” ,25 FUNCTION ,26 clk−>name ,27 new output freq ,28 clk−>max output freq ) ;29 }3031 /∗ Not i fy u s e r s o f change . ∗/32 f o r ( i =0; i < c lk−>use r count ; i++) {33 qemu se t i rq ( c lk−>user [ i ] , 1) ;34 }3536 /∗ Propagate the f requency change to the c h i l d c l o c k s ∗/37 f o r ( i =0; i < c lk−>output count ; i++) {38 n e x t c l k = clk−>output [ i ] ;39 a s s e r t ( n e x t c l k != NULL) ;4041 /∗ Only propagate the change i f the c h i l d has s e l e c t e d the cur rent42 ∗ c l o ck as input .43 ∗/44 n e x t c l k i n p u t = c l k t r e e g e t i n p u t c l k ( n e x t c l k ) ;45 i f ( n e x t c l k i n p u t == c lk ) {46 /∗ Recur s ive ly propagate changes . The c l o ck t r e e should not be47 ∗ too deep , so we shouldn ’ t have to r e c u r s e too many times .48 ∗/49 c l k t r e e s e t i n p u t f r e q ( next c lk , new output f req ) ;50 }51 }52 }53 }

Listing B.2: Helper Function to recalculate the Output frequency based on pre-scaler by applicationlogic

,

1 ∗Reg i s t e r Implemention ∗/2 // func t i on implements the read o f important b i t s that change the c l o ck s e l e c t i o n3 s t a t i c u i n t 3 2 t stm32 rcc RCC CR read ( s t r u c t stm32f407xx rcc ∗ s )4 {5 // s e t the c l o c k s6 const bool PLLON = true ; // c l k t r e e i s e n a b l e d ( s−>PLLCLK) ;7 const bool HSEON = true ; // c l k t r e e i s e n a b l e d ( s−>HSECLK) ;8 const bool HSION = true ; // c l k t r e e i s e n a b l e d ( s−>HSICLK9 const bool PLLI2SON = true ; // c l k t r e e i s e n a b l e d ( s−>PLLI2SCLK) ;

1011 // i f c l o ck i s s e t ready b i t i s s e t1213 re turn (14 GET BIT MASK (RCC CR PLLRDY BIT, PLLON) | GET BIT MASK(RCC CR PLLON BIT, PLLON)

|15 GET BIT MASK (RCC CR HSERDY BIT, HSEON) | GET BIT MASK(RCC CR HSEON BIT, HSEON)

|16 GET BIT MASK (RCC CR HSIRDY BIT , HSION) | GET BIT MASK(RCC CR HSION BIT , HSION)

|17 GET BIT MASK (RCC CR PLLI2SRDY BIT , PLLI2SON) | GET BIT MASK(

RCC CR PLLI2SON BIT , PLLI2SON)



18 ) ;19 }202122 /∗ f unc t i on implements the s e t t i n g o f c l o c k s i f the c l o c k s are not s e t a l r eady23 Only one can be s e l e c t e d at a time24 Implemetation i s f o r RCC CR ∗/2526 s t a t i c void stm32 rcc RCC CR write ( s t r u c t stm32f407xx rcc ∗ s , u i n t 3 2 t new value ,

bool i n i t )27 {28 bool new PLLON, new HSEON, new HSION , new PLLI2SON ;2930 new PLLON = IS BIT SET ( new value , RCC CR PLLON BIT) ;31 /∗ checks i f any other c l o ck i s s e t or PLL i s a l r eady s e t ∗/32 i f ( ( c l k t r e e i s e n a b l e d ( s−>PLLCLK) &&!new PLLON) &&33 s−>RCC CFGR SW == SW PLL SELECTED ) {34 p r i n t f ( ”PLL cannot be d i s ab l ed whi l e i t i s s e l e c t e d as the system c lock . ” ) ;35 }36 /∗ i f not s e t s the PLL c lo ck ∗/37 c l k t r e e s e t e n a b l e d ( s−>PLLCLK, new PLLON) ;3839 new HSEON=IS BIT SET ( new value , RCC CR HSEON BIT) ;40 /∗ checks i f any other c l o ck i s s e t or HSE i s a l r eady s e t ∗/41 i f ( ( c l k t r e e i s e n a b l e d ( s−>HSECLK)&& ! new HSEON) &&42 ( s−>RCC CFGR SW == SW HSE SELECTED | | s−>RCC CFGR SW ==SW PLL SELECTED) ) {43 p r i n t f ( ”HSE o s c i l l a t o r cannot be d i s ab l ed whi l e i t i s d r i v i n g the system c lock ”

) ;44 }45 c l k t r e e s e t e n a b l e d ( s−>HSECLK, new HSEON) ;4647 new HSION=IS BIT SET ( new value , RCC CR HSION BIT) ;48 /∗ checks i f any other c l o ck i s s e t or HSI i s a l r eady s e t ∗/49 i f ( ( c l k t r e e i s e n a b l e d ( s−>HSECLK) && ! new HSEON) &&50 ( s−>RCC CFGR SW == SW HSI SELECTED | | s−>RCC CFGR SW == SW PLL SELECTED) ) {51 p r i n t f ( ”HSI o s c i l l a t o r cannot be d i s ab l ed whi l e i t i s d r i v i n g the system c lock ”

) ;52 }53 c l k t r e e s e t e n a b l e d ( s−>HSICLK, new HSION) ;545556 new PLLI2SON = IS BIT SET ( new value , RCC CR PLLI2SON BIT) ;57 c l k t r e e s e t e n a b l e d ( s−>PLLI2SCLK , new PLLI2SON) ;5859 WARN UNIMPLEMENTED( new value , 1 << RCC CR CSSON BIT, RCC CR RESET VALUE) ;60 WARN UNIMPLEMENTED( new value , RCC CR HSICAL MASK, RCC CR RESET VALUE) ;61 WARN UNIMPLEMENTED( new value , RCC CR HSITRIM MASK, RCC CR RESET VALUE) ;6263 }646566 //RCC PLLCFGR r e g i s t e r implementation67 s t a t i c u i n t 3 2 t stm32 rcc RCC PLLCFGR read ( s t r u c t stm32f407xx rcc ∗ s ) {68 re turn s−>RCC PLLCFGR;69 }7071 s t a t i c void stm32 rcc RCC PLLCFGR write ( s t r u c t stm32f407xx rcc ∗ s , u i n t 3 2 t

new value , bool i n i t )72 {73 /∗PLLM d i v i s i o n f a c t o r ∗/ // uint8 because value ranges from 0−6374 const u i n t 8 t new PLLM = ( new value & RCC PLLCFGR PLLM MASK) >>

RCC PLLCFGR PLLM START;75 i f (new PLLM <= 1) {76 hw error ( ”PLLM d i v i s i o n f a c t o r cannot be 0 or 1 . Given %u” , new PLLM) ;77 }7879 /∗PLLN m u l t i p l i c a t i o n f a c t o r ∗/ // uint16 because value ranges from 0−511



80 const u i n t 1 6 t new PLLN = ( new value & RCC PLLCFGR PLLN MASK)>>RCC PLLCFGR PLLN START;

8182 i f (new PLLN <=1 | | new PLLN >=433) {83 hw error ( ”PLLN m u l t i p l i c a t i o n f a c t o r must be between 1 to 433( e x c l u s i v e ) . Given

: %u” , new PLLN) ;84 }8586 /∗PLLSRC∗/87 const u i n t 8 t new PLLSRC = IS BIT SET ( new value , RCC PLLCFGR PLLSRC BIT) ;8889 /∗PLLP d i v i s i o n f a c t o r ∗/90 const u i n t 8 t new PLLP = 2 + (2 ∗ ( ( new value & RCC PLLCFGR PLLP MASK) >>

RCC PLLCFGR PLLP START) ) ;9192 // i n c o r r e c t w r i t e s warning9394 i f ( i n i t ==f a l s e ) {95 const bool a r e d i s a b l e d = ( ! c l k t r e e i s e n a b l e d ( s−>PLLCLK) ) ;96 i f ( a r e d i s a b l e d == f a l s e ) { // PLLM i s a l r eady running97 const char ∗warning fmt = ”Can only change %s whi l e PLL i s d i s ab l ed \n” ;98 i f (new PLLM != s−>RCC PLLCFGR PLLM) {99 p r i n t f ( warning fmt , ”PLLM” ) ; // new value i s not same as value s e t in

r e g i s t e r100 }101 i f (new PLLN != s−>RCC PLLCFGR PLLN) {102 p r i n t f ( warning fmt , ”PLLN” ) ;103 }104 i f (new PLLSRC != s−>RCC PLLCFGR PLLSRC) {105 p r i n t f ( warning fmt , ”PLLSRC” ) ;106 }107 }108 }109110 // save the new c lock va lue s111 s−>RCC PLLCFGR =new value ;112113 /∗ s e t the new va lue s ∗/114 s−>RCC PLLCFGR PLLM = new PLLM ;115 s−>RCC PLLCFGR PLLN = new PLLN ;116 c l k t r e e s e t s c a l e ( s−>PLLM, new PLLN , new PLLM) ;117118 s−>RCC PLLCFGR PLLSRC =new PLLSRC ;119 c l k t r e e s e t s e l e c t e d i n p u t ( s−>PLLM, new PLLSRC) ;120121 s−>RCC PLLCFGR PLLP =new PLLP ;122 c l k t r e e s e t s c a l e ( s−>PLLCLK, 1 , new PLLP) ;123124 WARN UNIMPLEMENTED( new value , RCC PLLCFGR PLLQ MASK, RCC PLLCFGR RESET VALUE) ;125126 }127128129130 //RCC CFGR r e g i s t e r implementation131 s t a t i c u i n t 3 2 t stm32 rcc RCC CFGR read ( s t r u c t stm32f407xx rcc ∗ s )132 {133 re turn134 ( s−>RCC CFGR PPRE2 << RCC CFGR PPRE2 START) |135 ( s−>RCC CFGR PPRE1 << RCC CFGR PPRE1 START) |136 ( s−>RCC CFGR HPRE << RCC CFGR HPRE START) |137 ( s−>RCC CFGR SW << RCC CFGR SW START) |138 ( s−>RCC CFGR SW << RCC CFGR SWS START) ;139 }140141 s t a t i c void stm32 rcc RCC CFGR write ( s t r u c t stm32f407xx rcc ∗ s , u i n t 3 2 t new value ,

bool i n i t )



142 {143 /∗PPRE2144 s c a l i n g i s done by 2/4/8/16 f o r APB2 ∗/145 s−>RCC CFGR PPRE2 = ( new value & RCC CFGR PPRE2 MASK) >> RCC CFGR PPRE2 START;146 i f ( s−>RCC CFGR PPRE2 < 0x4 ) {147 c l k t r e e s e t s c a l e ( s−>PCLK2, 1 , 1) ;148 }149 e l s e {150 c l k t r e e s e t s c a l e ( s−>PCLK2, 1 , 2 ∗ ( s−>RCC CFGR PPRE2 − 3) ) ;151 }152153 /∗ PPRE1154 s c a l i n g i s done by 2/4/8/16 f o r APB1 ∗/155 s−>RCC CFGR PPRE1 = ( new value & RCC CFGR PPRE1 MASK) >> RCC CFGR PPRE1 START;156 i f ( s−>RCC CFGR PPRE1 < 4) {157 c l k t r e e s e t s c a l e ( s−>PCLK1, 1 , 1) ;158 }159 e l s e {160 c l k t r e e s e t s c a l e ( s−>PCLK1, 1 , 2 ∗ ( s−>RCC CFGR PPRE1 − 3) ) ;161 }162163164 /∗HPRE165 s c a l i n g i s done by 2 / 4 / 8 / 1 6 . . . . / 5 1 2 f o r AHB ∗/166 s−>RCC CFGR HPRE =(new value & RCC CFGR HPRE MASK) >> RCC CFGR HPRE START;167 i f ( s−>RCC CFGR HPRE < 8) {168 c l k t r e e s e t s c a l e ( s−>HCLK, 1 , 1) ;169 }170 e l s e {171 c l k t r e e s e t s c a l e ( s−>HCLK, 1 , 2∗ ( s−>RCC CFGR HPRE − 7) ) ;172 }173174 /∗sw∗/175176 s−>RCC CFGR SW = ( new value & RCC CFGR SW MASK) >> RCC CFGR SW START;177 switch ( s−>RCC CFGR SW) {178 case 0x0 :179 case 0x1 :180 case 0x2 :181 c l k t r e e s e t s e l e c t e d i n p u t ( s−>SYSCLK, s−>RCC CFGR SW) ;182 break ;183 d e f a u l t :184 hw error ( ” I n v a l i d input s e l e c t e d f o r SYSCLK” ) ;185 break ;186187 }188 WARN UNIMPLEMENTED( new value , RCC CFGR MCO2 MASK, RCC CFGR RESET VALUE) ;189 WARN UNIMPLEMENTED( new value , RCC CFGR MCO2PRE MASK, RCC CFGR RESET VALUE) ;190 WARN UNIMPLEMENTED( new value , RCC CFGR MCO1PRE MASK, RCC CFGR RESET VALUE) ;191 WARN UNIMPLEMENTED( new value , 1 << RCC CFGR I2SSRC BIT , RCC CFGR RESET VALUE) ;192 WARN UNIMPLEMENTED( new value , RCC CFGR MCO1 MASK, RCC CFGR RESET VALUE) ;193 WARN UNIMPLEMENTED( new value , RCC CFGR RTCPRE MASK, RCC CFGR RESET VALUE) ;194 WARN UNIMPLEMENTED( new value , RCC CFGR SWS MASK, RCC CFGR RESET VALUE) ;195196 }

Listing B.3: Register implementation to set up clock tree for RCC CR,RCC CFGR,RCC PLLCFGR


Appendix C

Performance Analysis

1 sups@sups−Insp i ron −3421:˜/Documents/stm32/qemu$ qemu−system−arm −machinestm32f407ve scu −d unimp −ke rne l t e s t . b inary

2 STM32F2407 RCC : Cortex SYSTICK frequency s e t to 16000000 Hz ( s c a l e s e t to 62) .3 r cc s e t 0x0 SYSCFG 10 e : d i s a b l e4 Not implemented : RCC RCC CR HSITRIM MASK. Masked value : 0x000000005 Not implemented : RCC RCC CR HSITRIM MASK. Masked value : 0x000000006 Not implemented : RCC RCC CR HSITRIM MASK. Masked value : 0x000000007 rcc s e t 0x4000 SYSCFG 10 e : enable8 Not implemented : RCC 1 << RCC APB1ENR PWREN BIT. Masked value : 0x100000009 Not implemented : RCC 1 << RCC APB1ENR PWREN BIT. Masked value : 0x10000000

10 Not implemented : RCC 1 << RCC AHB1ENR CCMDATARAMEN BIT. Masked value : 0x0000000011 Not implemented : RCC 1 << RCC AHB1ENR CCMDATARAMEN BIT. Masked value : 0x0000000012 Not implemented : RCC 1 << RCC AHB1ENR CCMDATARAMEN BIT. Masked value : 0x0000000013 Not implemented : RCC 1 << RCC AHB1ENR CCMDATARAMEN BIT. Masked value : 0x0000000014 Not implemented : RCC 1 << RCC AHB1ENR CCMDATARAMEN BIT. Masked value : 0x0000000015 Not implemented : RCC 1 << RCC AHB1ENR CCMDATARAMEN BIT. Masked value : 0x000000001617 stm32f407xx gpio : GPIOE PE0 : mode s e t to Analog18 stm32f407xx gpio : GPIOE PE1 : mode s e t to Analog19 stm32f407xx gpio : GPIOE PE2 : mode s e t to Analog20 stm32f407xx gpio : GPIOE PE3 : mode s e t to Analog21 stm32f407xx gpio : GPIOE PE4 : mode s e t to Analog22 stm32f407xx gpio : GPIOE PE5 : mode s e t to Analog23 stm32f407xx gpio : GPIOE PE6 : mode s e t to Analog24 stm32f407xx gpio : GPIOE PE7 : mode s e t to Analog25 stm32f407xx gpio : GPIOE PE8 : mode s e t to Analog26 stm32f407xx gpio : GPIOE PE9 : mode s e t to Analog27 stm32f407xx gpio : GPIOE PE10 : mode s e t to Analog28 stm32f407xx gpio : GPIOE PE11 : mode s e t to Analog29 stm32f407xx gpio : GPIOE PE12 : mode s e t to Analog30 stm32f407xx gpio : GPIOE PE13 : mode s e t to Analog31 stm32f407xx gpio : GPIOE PE14 : mode s e t to Analog32 stm32f407xx gpio : GPIOE PE15 : mode s e t to Analog33 stm32f407xx gpio : GPIOC PC13 : mode s e t to Output34 stm32f407xx gpio : GPIOC PC0 : mode s e t to Analog35 stm32f407xx gpio : GPIOC PC1 : mode s e t to Analog36 stm32f407xx gpio : GPIOC PC2 : mode s e t to Analog37 stm32f407xx gpio : GPIOC PC3 : mode s e t to Analog38 stm32f407xx gpio : GPIOC PC4 : mode s e t to Analog39 stm32f407xx gpio : GPIOC PC5 : mode s e t to Analog40 stm32f407xx gpio : GPIOC PC6 : mode s e t to Analog41 stm32f407xx gpio : GPIOC PC7 : mode s e t to Analog42 stm32f407xx gpio : GPIOC PC8 : mode s e t to Analog43 stm32f407xx gpio : GPIOC PC9 : mode s e t to Analog44 stm32f407xx gpio : GPIOC PC10 : mode s e t to Analog45 stm32f407xx gpio : GPIOC PC11 : mode s e t to Analog46 stm32f407xx gpio : GPIOC PC12 : mode s e t to Analog47 stm32f407xx gpio : GPIOC PC14 : mode s e t to Analog


APPENDIX C. PERFORMANCE ANALYSIS

48 stm32f407xx gpio : GPIOC PC15 : mode s e t to Analog49 stm32f407xx gpio : GPIOH PH0: mode s e t to Analog50 stm32f407xx gpio : GPIOH PH1: mode s e t to Analog51 stm32f407xx gpio : GPIOA PA0: mode s e t to Analog52 stm32f407xx gpio : GPIOA PA1: mode s e t to Analog53 stm32f407xx gpio : GPIOA PA2: mode s e t to Analog54 stm32f407xx gpio : GPIOA PA3: mode s e t to Analog55 stm32f407xx gpio : GPIOA PA4: mode s e t to Analog56 stm32f407xx gpio : GPIOA PA5: mode s e t to Analog57 stm32f407xx gpio : GPIOA PA6: mode s e t to Analog58 stm32f407xx gpio : GPIOA PA7: mode s e t to Analog59 stm32f407xx gpio : GPIOA PA8: mode s e t to Analog60 stm32f407xx gpio : GPIOA PA9: mode s e t to Analog61 stm32f407xx gpio : GPIOA PA10 : mode s e t to Analog62 stm32f407xx gpio : GPIOA PA11 : mode s e t to Analog63 stm32f407xx gpio : GPIOA PA12 : mode s e t to Analog64 stm32f407xx gpio : GPIOA PA15 : mode s e t to Analog65 stm32f407xx gpio : GPIOA PA15 : pu/pd s e t to : No pul lup / pulldown66 stm32f407xx gpio : GPIOB PB0 : mode s e t to Analog67 stm32f407xx gpio : GPIOB PB1 : mode s e t to Analog68 stm32f407xx gpio : GPIOB PB2 : mode s e t to Analog69 stm32f407xx gpio : GPIOB PB3 : mode s e t to Analog70 stm32f407xx gpio : GPIOB PB4 : mode s e t to Analog71 stm32f407xx gpio : GPIOB PB4 : pu/pd s e t to : No pul lup / pulldown72 stm32f407xx gpio : GPIOB PB5 : mode s e t to Analog73 stm32f407xx gpio : GPIOB PB6 : mode s e t to Analog74 stm32f407xx gpio : GPIOB PB7 : mode s e t to Analog75 stm32f407xx gpio : GPIOB PB8 : mode s e t to Analog76 stm32f407xx gpio : GPIOB PB9 : mode s e t to Analog77 stm32f407xx gpio : GPIOB PB10 : mode s e t to Analog78 stm32f407xx gpio : GPIOB PB11 : mode s e t to Analog79 stm32f407xx gpio : GPIOB PB12 : mode s e t to Analog80 stm32f407xx gpio : GPIOB PB13 : mode s e t to Analog81 stm32f407xx gpio : GPIOB PB14 : mode s e t to Analog82 stm32f407xx gpio : GPIOB PB15 : mode s e t to Analog83 stm32f407xx gpio : GPIOD PD0: mode s e t to Analog84 stm32f407xx gpio : GPIOD PD1: mode s e t to Analog85 stm32f407xx gpio : GPIOD PD2: mode s e t to Analog86 stm32f407xx gpio : GPIOD PD3: mode s e t to Analog87 stm32f407xx gpio : GPIOD PD4: mode s e t to Analog88 stm32f407xx gpio : GPIOD PD5: mode s e t to Analog89 stm32f407xx gpio : GPIOD PD6: mode s e t to Analog90 stm32f407xx gpio : GPIOD PD7: mode s e t to Analog91 stm32f407xx gpio : GPIOD PD8: mode s e t to Analog92 stm32f407xx gpio : GPIOD PD9: mode s e t to Analog93 stm32f407xx gpio : GPIOD PD10 : mode s e t to Analog94 stm32f407xx gpio : GPIOD PD11 : mode s e t to Analog95 stm32f407xx gpio : GPIOD PD12 : mode s e t to Analog96 stm32f407xx gpio : GPIOD PD13 : mode s e t to Analog97 stm32f407xx gpio : GPIOD PD14 : mode s e t to Analog98 stm32f407xx gpio : GPIOD PD15 : mode s e t to Analog

Listing C.1: Test for Modularity showing QEMU unimplemented register warnings

C.1 Test cases

1 sups@sups−Insp i ron −3421:˜/Documents/stm32/qemu$ qemu−system−arm −machinestm32f407ve scu −ke rne l t e s t 1 . b inary

2 STM32F2407 RCC : Cortex SYSTICK frequency s e t to 16000000 Hz .3 r cc s e t 0x0 SYSCFG 10 e : d i s a b l e4 r cc s e t 0x4000 SYSCFG 10 e : enable5 stm32f407xx gpio : Time i s 1563482556674 GPIOA PA10 : wr i t e va lue 06 stm32f407xx gpio : GPIOE PE0 : mode s e t to Analog7 stm32f407xx gpio : GPIOE PE1 : mode s e t to Analog8 stm32f407xx gpio : GPIOE PE2 : mode s e t to Analog



9 stm32f407xx gpio : GPIOE PE3 : mode s e t to Analog10 stm32f407xx gpio : GPIOE PE4 : mode s e t to Analog11 stm32f407xx gpio : GPIOE PE5 : mode s e t to Analog12 stm32f407xx gpio : GPIOE PE6 : mode s e t to Analog13 stm32f407xx gpio : GPIOE PE7 : mode s e t to Analog14 stm32f407xx gpio : GPIOE PE8 : mode s e t to Analog15 stm32f407xx gpio : GPIOE PE9 : mode s e t to Analog16 stm32f407xx gpio : GPIOE PE10 : mode s e t to Analog17 stm32f407xx gpio : GPIOE PE11 : mode s e t to Analog18 stm32f407xx gpio : GPIOE PE12 : mode s e t to Analog19 stm32f407xx gpio : GPIOE PE13 : mode s e t to Analog20 stm32f407xx gpio : GPIOE PE14 : mode s e t to Analog21 stm32f407xx gpio : GPIOE PE15 : mode s e t to Analog22 stm32f407xx gpio : GPIOC PC0 : mode s e t to Analog23 stm32f407xx gpio : GPIOC PC1 : mode s e t to Analog24 stm32f407xx gpio : GPIOC PC2 : mode s e t to Analog25 stm32f407xx gpio : GPIOC PC3 : mode s e t to Analog26 stm32f407xx gpio : GPIOC PC4 : mode s e t to Analog27 stm32f407xx gpio : GPIOC PC5 : mode s e t to Analog28 stm32f407xx gpio : GPIOC PC6 : mode s e t to Analog29 stm32f407xx gpio : GPIOC PC7 : mode s e t to Analog30 stm32f407xx gpio : GPIOC PC8 : mode s e t to Analog31 stm32f407xx gpio : GPIOC PC9 : mode s e t to Analog32 stm32f407xx gpio : GPIOC PC10 : mode s e t to Analog33 stm32f407xx gpio : GPIOC PC11 : mode s e t to Analog34 stm32f407xx gpio : GPIOC PC12 : mode s e t to Analog35 stm32f407xx gpio : GPIOC PC13 : mode s e t to Analog36 stm32f407xx gpio : GPIOC PC14 : mode s e t to Analog37 stm32f407xx gpio : GPIOC PC15 : mode s e t to Analog38 stm32f407xx gpio : GPIOA PA0: mode s e t to Analog39 stm32f407xx gpio : GPIOA PA1: mode s e t to Analog40 stm32f407xx gpio : GPIOA PA2: mode s e t to Analog41 stm32f407xx gpio : GPIOA PA3: mode s e t to Analog42 stm32f407xx gpio : GPIOA PA4: mode s e t to Analog43 stm32f407xx gpio : GPIOA PA5: mode s e t to Analog44 stm32f407xx gpio : GPIOA PA6: mode s e t to Analog45 stm32f407xx gpio : GPIOA PA7: mode s e t to Analog46 stm32f407xx gpio : GPIOA PA8: mode s e t to Analog47 stm32f407xx gpio : GPIOA PA9: mode s e t to Analog48 stm32f407xx gpio : GPIOA PA12 : mode s e t to Analog49 stm32f407xx gpio : GPIOA PA13 : mode s e t to Analog50 stm32f407xx gpio : GPIOA PA13 : pu/pd s e t to : No pul lup / pulldown51 stm32f407xx gpio : GPIOA PA14 : mode s e t to Analog52 stm32f407xx gpio : GPIOA PA14 : pu/pd s e t to : No pul lup / pulldown53 stm32f407xx gpio : GPIOA PA15 : mode s e t to Analog54 stm32f407xx gpio : GPIOA PA15 : pu/pd s e t to : No pul lup / pulldown55 stm32f407xx gpio : GPIOB PB0 : mode s e t to Analog56 stm32f407xx gpio : GPIOB PB1 : mode s e t to Analog57 stm32f407xx gpio : GPIOB PB2 : mode s e t to Analog58 stm32f407xx gpio : GPIOB PB3 : mode s e t to Analog59 stm32f407xx gpio : GPIOB PB4 : mode s e t to Analog60 stm32f407xx gpio : GPIOB PB4 : pu/pd s e t to : No pul lup / pulldown61 stm32f407xx gpio : GPIOB PB5 : mode s e t to Analog62 stm32f407xx gpio : GPIOB PB6 : mode s e t to Analog63 stm32f407xx gpio : GPIOB PB7 : mode s e t to Analog64 stm32f407xx gpio : GPIOB PB8 : mode s e t to Analog65 stm32f407xx gpio : GPIOB PB9 : mode s e t to Analog66 stm32f407xx gpio : GPIOB PB10 : mode s e t to Analog67 stm32f407xx gpio : GPIOB PB11 : mode s e t to Analog68 stm32f407xx gpio : GPIOB PB12 : mode s e t to Analog69 stm32f407xx gpio : GPIOB PB13 : mode s e t to Analog70 stm32f407xx gpio : GPIOB PB14 : mode s e t to Analog71 stm32f407xx gpio : GPIOB PB15 : mode s e t to Analog72 stm32f407xx gpio : GPIOD PD0: mode s e t to Analog73 stm32f407xx gpio : GPIOD PD1: mode s e t to Analog74 stm32f407xx gpio : GPIOD PD2: mode s e t to Analog75 stm32f407xx gpio : GPIOD PD3: mode s e t to Analog



76 stm32f407xx gpio : GPIOD PD4: mode s e t to Analog77 stm32f407xx gpio : GPIOD PD5: mode s e t to Analog78 stm32f407xx gpio : GPIOD PD6: mode s e t to Analog79 stm32f407xx gpio : GPIOD PD7: mode s e t to Analog80 stm32f407xx gpio : GPIOD PD8: mode s e t to Analog81 stm32f407xx gpio : GPIOD PD9: mode s e t to Analog82 stm32f407xx gpio : GPIOD PD10 : mode s e t to Analog83 stm32f407xx gpio : GPIOD PD11 : mode s e t to Analog84 stm32f407xx gpio : GPIOD PD12 : mode s e t to Analog85 stm32f407xx gpio : GPIOD PD13 : mode s e t to Analog86 stm32f407xx gpio : GPIOD PD14 : mode s e t to Analog87 stm32f407xx gpio : GPIOD PD15 : mode s e t to Analog88 stm32f407xx gpio : GPIOA PA10 : mode s e t to Output89 stm32f407xx gpio : Time i s 0 GPIOA PA10 : wr i t e va lue 190 stm32f407xx gpio : Time i s 106 GPIOA PA10 : wr i t e va lue 091 stm32f407xx gpio : Time i s 101 GPIOA PA10 : wr i t e va lue 192 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 093 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 194 stm32f407xx gpio : Time i s 105 GPIOA PA10 : wr i t e va lue 095 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 196 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 097 stm32f407xx gpio : Time i s 106 GPIOA PA10 : wr i t e va lue 198 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 099 stm32f407xx gpio : Time i s 108 GPIOA PA10 : wr i t e va lue 1

100 stm32f407xx gpio : Time i s 101 GPIOA PA10 : wr i t e va lue 0101 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 1102 stm32f407xx gpio : Time i s 105 GPIOA PA10 : wr i t e va lue 0103 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 1104 stm32f407xx gpio : Time i s 105 GPIOA PA10 : wr i t e va lue 0105 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 1106 stm32f407xx gpio : Time i s 101 GPIOA PA10 : wr i t e va lue 0107 stm32f407xx gpio : Time i s 106 GPIOA PA10 : wr i t e va lue 1108 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 0109 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 1110 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 0111 stm32f407xx gpio : Time i s 101 GPIOA PA10 : wr i t e va lue 1112 stm32f407xx gpio : Time i s 103 GPIOA PA10 : wr i t e va lue 0113 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 1114 stm32f407xx gpio : Time i s 105 GPIOA PA10 : wr i t e va lue 0115 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 1116 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 0117 stm32f407xx gpio : Time i s 109 GPIOA PA10 : wr i t e va lue 1118 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 0119 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 1120 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 0121 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 1122 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 0123 stm32f407xx gpio : Time i s 101 GPIOA PA10 : wr i t e va lue 1124 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 0125 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 1126 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 0127 stm32f407xx gpio : Time i s 107 GPIOA PA10 : wr i t e va lue 1128 stm32f407xx gpio : Time i s 101 GPIOA PA10 : wr i t e va lue 0129 stm32f407xx gpio : Time i s 106 GPIOA PA10 : wr i t e va lue 1130 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 0131 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 1132 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 0133 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 1134 stm32f407xx gpio : Time i s 107 GPIOA PA10 : wr i t e va lue 0135 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 1136 stm32f407xx gpio : Time i s 106 GPIOA PA10 : wr i t e va lue 0137 stm32f407xx gpio : Time i s 99 GPIOA PA10 : wr i t e va lue 1138 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 0139 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 1140 stm32f407xx gpio : Time i s 101 GPIOA PA10 : wr i t e va lue 0141 stm32f407xx gpio : Time i s 108 GPIOA PA10 : wr i t e va lue 1142 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 0



143 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 1144 stm32f407xx gpio : Time i s 105 GPIOA PA10 : wr i t e va lue 0145 stm32f407xx gpio : Time i s 101 GPIOA PA10 : wr i t e va lue 1146 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 0147 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 1148 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 0149 stm32f407xx gpio : Time i s 108 GPIOA PA10 : wr i t e va lue 1150 stm32f407xx gpio : Time i s 100 GPIOA PA10 : wr i t e va lue 0151 stm32f407xx gpio : Time i s 108 GPIOA PA10 : wr i t e va lue 1152 stm32f407xx gpio : Time i s 101 GPIOA PA10 : wr i t e va lue 0

Listing C.2: Test case 1 output

1 sups@sups−Insp i ron −3421:˜/ Downloads$ qemu−system−arm −machine stm32f407ve scu −ke rne l t e s t 2 . b inary

2 STM32F2407 RCC : Cortex SYSTICK frequency s e t to 16000000 Hz .3 r cc s e t 0x0 SYSCFG 10 e : d i s a b l e4 r cc s e t 0x4000 SYSCFG 10 e : enable5 stm32f407xx gpio : Time i s 8 GPIOA PA5: wr i t e va lue 06 stm32f407xx gpio : Time i s 8 GPIOA PA6: wr i t e va lue 07 stm32f407xx gpio : Time i s 8 GPIOA PA9: wr i t e va lue 08 stm32f407xx gpio : Time i s 8 GPIOA PA10 : wr i t e va lue 09 stm32f407xx gpio : Time i s 8 GPIOA PA11 : wr i t e va lue 0

10 stm32f407xx gpio : Time i s 0 GPIOE PE12 : wr i t e va lue 011 stm32f407xx gpio : Time i s 0 GPIOE PE13 : wr i t e va lue 012 stm32f407xx gpio : GPIOE PE0 : mode s e t to Analog13 stm32f407xx gpio : GPIOE PE1 : mode s e t to Analog14 stm32f407xx gpio : GPIOE PE2 : mode s e t to Analog15 stm32f407xx gpio : GPIOE PE3 : mode s e t to Analog16 stm32f407xx gpio : GPIOE PE4 : mode s e t to Analog17 stm32f407xx gpio : GPIOE PE5 : mode s e t to Analog18 stm32f407xx gpio : GPIOE PE6 : mode s e t to Analog19 stm32f407xx gpio : GPIOE PE7 : mode s e t to Analog20 stm32f407xx gpio : GPIOE PE8 : mode s e t to Analog21 stm32f407xx gpio : GPIOE PE9 : mode s e t to Analog22 stm32f407xx gpio : GPIOE PE10 : mode s e t to Analog23 stm32f407xx gpio : GPIOE PE11 : mode s e t to Analog24 stm32f407xx gpio : GPIOE PE14 : mode s e t to Analog25 stm32f407xx gpio : GPIOE PE15 : mode s e t to Analog26 stm32f407xx gpio : GPIOC PC0 : mode s e t to Analog27 stm32f407xx gpio : GPIOC PC1 : mode s e t to Analog28 stm32f407xx gpio : GPIOC PC2 : mode s e t to Analog29 stm32f407xx gpio : GPIOC PC3 : mode s e t to Analog30 stm32f407xx gpio : GPIOC PC4 : mode s e t to Analog31 stm32f407xx gpio : GPIOC PC5 : mode s e t to Analog32 stm32f407xx gpio : GPIOC PC6 : mode s e t to Analog33 stm32f407xx gpio : GPIOC PC7 : mode s e t to Analog34 stm32f407xx gpio : GPIOC PC8 : mode s e t to Analog35 stm32f407xx gpio : GPIOC PC9 : mode s e t to Analog36 stm32f407xx gpio : GPIOC PC10 : mode s e t to Analog37 stm32f407xx gpio : GPIOC PC11 : mode s e t to Analog38 stm32f407xx gpio : GPIOC PC12 : mode s e t to Analog39 stm32f407xx gpio : GPIOC PC13 : mode s e t to Analog40 stm32f407xx gpio : GPIOC PC14 : mode s e t to Analog41 stm32f407xx gpio : GPIOC PC15 : mode s e t to Analog42 stm32f407xx gpio : GPIOA PA0: mode s e t to Analog43 stm32f407xx gpio : GPIOA PA1: mode s e t to Analog44 stm32f407xx gpio : GPIOA PA2: mode s e t to Analog45 stm32f407xx gpio : GPIOA PA3: mode s e t to Analog46 stm32f407xx gpio : GPIOA PA4: mode s e t to Analog47 stm32f407xx gpio : GPIOA PA7: mode s e t to Analog48 stm32f407xx gpio : GPIOA PA8: mode s e t to Analog49 stm32f407xx gpio : GPIOA PA13 : mode s e t to Analog50 stm32f407xx gpio : GPIOA PA13 : pu/pd s e t to : No pul lup / pulldown51 stm32f407xx gpio : GPIOA PA14 : mode s e t to Analog52 stm32f407xx gpio : GPIOA PA14 : pu/pd s e t to : No pul lup / pulldown53 stm32f407xx gpio : GPIOA PA15 : mode s e t to Analog



54 stm32f407xx gpio : GPIOA PA15 : pu/pd s e t to : No pul lup / pulldown55 stm32f407xx gpio : GPIOA PA5: mode s e t to Output56 stm32f407xx gpio : GPIOA PA6: mode s e t to Output57 stm32f407xx gpio : GPIOA PA9: mode s e t to Output58 stm32f407xx gpio : GPIOA PA10 : mode s e t to Output59 stm32f407xx gpio : GPIOA PA11 : mode s e t to Output60 stm32f407xx gpio : GPIOB PB0 : mode s e t to Analog61 stm32f407xx gpio : GPIOB PB1 : mode s e t to Analog62 stm32f407xx gpio : GPIOB PB2 : mode s e t to Analog63 stm32f407xx gpio : GPIOB PB3 : mode s e t to Analog64 stm32f407xx gpio : GPIOB PB4 : mode s e t to Analog65 stm32f407xx gpio : GPIOB PB4 : pu/pd s e t to : No pul lup / pulldown66 stm32f407xx gpio : GPIOB PB5 : mode s e t to Analog67 stm32f407xx gpio : GPIOB PB6 : mode s e t to Analog68 stm32f407xx gpio : GPIOB PB7 : mode s e t to Analog69 stm32f407xx gpio : GPIOB PB8 : mode s e t to Analog70 stm32f407xx gpio : GPIOB PB9 : mode s e t to Analog71 stm32f407xx gpio : GPIOB PB10 : mode s e t to Analog72 stm32f407xx gpio : GPIOB PB11 : mode s e t to Analog73 stm32f407xx gpio : GPIOB PB12 : mode s e t to Analog74 stm32f407xx gpio : GPIOB PB13 : mode s e t to Analog75 stm32f407xx gpio : GPIOB PB14 : mode s e t to Analog76 stm32f407xx gpio : GPIOB PB15 : mode s e t to Analog77 stm32f407xx gpio : GPIOE PE12 : mode s e t to Output78 stm32f407xx gpio : GPIOE PE13 : mode s e t to Output79 stm32f407xx gpio : GPIOD PD0: mode s e t to Analog80 stm32f407xx gpio : GPIOD PD1: mode s e t to Analog81 stm32f407xx gpio : GPIOD PD2: mode s e t to Analog82 stm32f407xx gpio : GPIOD PD3: mode s e t to Analog83 stm32f407xx gpio : GPIOD PD4: mode s e t to Analog84 stm32f407xx gpio : GPIOD PD5: mode s e t to Analog85 stm32f407xx gpio : GPIOD PD6: mode s e t to Analog86 stm32f407xx gpio : GPIOD PD7: mode s e t to Analog87 stm32f407xx gpio : GPIOD PD8: mode s e t to Analog88 stm32f407xx gpio : GPIOD PD9: mode s e t to Analog89 stm32f407xx gpio : GPIOD PD10 : mode s e t to Analog90 stm32f407xx gpio : GPIOD PD11 : mode s e t to Analog91 stm32f407xx gpio : GPIOD PD12 : mode s e t to Analog92 stm32f407xx gpio : GPIOD PD13 : mode s e t to Analog93 stm32f407xx gpio : GPIOD PD14 : mode s e t to Analog94 stm32f407xx gpio : GPIOD PD15 : mode s e t to Analog95 stm32f407xx gpio : Time i s 0 GPIOA PA10 : wr i t e va lue 196 stm32f407xx gpio : Time i s 110 GPIOA PA5: wr i t e va lue 197 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 198 stm32f407xx gpio : Time i s 106 GPIOA PA9: wr i t e va lue 199 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 1

100 stm32f407xx gpio : Time i s 117 GPIOA PA10 : wr i t e va lue 0101 stm32f407xx gpio : Time i s 99 GPIOA PA5: wr i t e va lue 0102 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 0103 stm32f407xx gpio : Time i s 105 GPIOA PA9: wr i t e va lue 0104 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 0105 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 1106 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 1107 stm32f407xx gpio : Time i s 106 GPIOA PA6: wr i t e va lue 1108 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 1109 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 1110 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 0111 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 0112 stm32f407xx gpio : Time i s 106 GPIOA PA6: wr i t e va lue 0113 stm32f407xx gpio : Time i s 99 GPIOA PA9: wr i t e va lue 0114 stm32f407xx gpio : Time i s 101 GPIOA PA11 : wr i t e va lue 0115 stm32f407xx gpio : Time i s 105 GPIOA PA10 : wr i t e va lue 1116 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 1117 stm32f407xx gpio : Time i s 108 GPIOA PA6: wr i t e va lue 1118 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 1119 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 1120 stm32f407xx gpio : Time i s 106 GPIOA PA10 : wr i t e va lue 0



121 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 0122 stm32f407xx gpio : Time i s 108 GPIOA PA6: wr i t e va lue 0123 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 0124 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 0125 stm32f407xx gpio : Time i s 108 GPIOA PA10 : wr i t e va lue 1126 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 1127 stm32f407xx gpio : Time i s 104 GPIOA PA6: wr i t e va lue 1128 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 1129 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 1130 stm32f407xx gpio : Time i s 107 GPIOA PA10 : wr i t e va lue 0131 stm32f407xx gpio : Time i s 101 GPIOA PA5: wr i t e va lue 0132 stm32f407xx gpio : Time i s 108 GPIOA PA6: wr i t e va lue 0133 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 0134 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 0135 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 1136 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 1137 stm32f407xx gpio : Time i s 105 GPIOA PA6: wr i t e va lue 1138 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 1139 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 1140 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 0141 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 0142 stm32f407xx gpio : Time i s 110 GPIOA PA6: wr i t e va lue 0143 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 0144 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 0145 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 1146 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 1147 stm32f407xx gpio : Time i s 105 GPIOA PA6: wr i t e va lue 1148 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 1149 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 1150 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 0151 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 0152 stm32f407xx gpio : Time i s 109 GPIOA PA6: wr i t e va lue 0153 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 0154 stm32f407xx gpio : Time i s 101 GPIOA PA11 : wr i t e va lue 0155 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 1156 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 1157 stm32f407xx gpio : Time i s 104 GPIOA PA6: wr i t e va lue 1158 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 1159 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 1160 stm32f407xx gpio : Time i s 106 GPIOA PA10 : wr i t e va lue 0161 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 0162 stm32f407xx gpio : Time i s 108 GPIOA PA6: wr i t e va lue 0163 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 0164 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 0165 stm32f407xx gpio : Time i s 105 GPIOA PA10 : wr i t e va lue 1166 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 1167 stm32f407xx gpio : Time i s 107 GPIOA PA6: wr i t e va lue 1168 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 1169 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 1170 stm32f407xx gpio : Time i s 107 GPIOA PA10 : wr i t e va lue 0171 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 0172 stm32f407xx gpio : Time i s 105 GPIOA PA6: wr i t e va lue 0173 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 0174 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 0175 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 1176 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 1177 stm32f407xx gpio : Time i s 109 GPIOA PA6: wr i t e va lue 1178 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 1179 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 1180 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 0181 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 0182 stm32f407xx gpio : Time i s 105 GPIOA PA6: wr i t e va lue 0183 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 0184 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 0185 stm32f407xx gpio : Time i s 104 GPIOA PA10 : wr i t e va lue 1186 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 1187 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 1



188 stm32f407xx gpio : Time i s 108 GPIOA PA9: wr i t e va lue 1189 stm32f407xx gpio : Time i s 101 GPIOA PA11 : wr i t e va lue 1190 stm32f407xx gpio : Time i s 107 GPIOA PA10 : wr i t e va lue 0191 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 0192 stm32f407xx gpio : Time i s 105 GPIOA PA6: wr i t e va lue 0193 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 0194 stm32f407xx gpio : Time i s 101 GPIOA PA11 : wr i t e va lue 0195 stm32f407xx gpio : Time i s 105 GPIOA PA10 : wr i t e va lue 1196 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 1197 stm32f407xx gpio : Time i s 105 GPIOA PA6: wr i t e va lue 1198 stm32f407xx gpio : Time i s 99 GPIOA PA9: wr i t e va lue 1199 stm32f407xx gpio : Time i s 100 GPIOA PA11 : wr i t e va lue 1200 stm32f407xx gpio : Time i s 106 GPIOA PA10 : wr i t e va lue 0201 stm32f407xx gpio : Time i s 100 GPIOA PA5: wr i t e va lue 0202 stm32f407xx gpio : Time i s 107 GPIOA PA6: wr i t e va lue 0203 stm32f407xx gpio : Time i s 100 GPIOA PA9: wr i t e va lue 0


12 sups@sups−Insp i ron −3421:˜/ Downloads$ qemu−system−arm −machine stm32f407ve scu −

ke rne l t e s t 3 . b inary3 STM32F2407 RCC : Cortex SYSTICK frequency s e t to 16000000 Hz .4 r cc s e t 0x0 SYSCFG 10 e : d i s a b l e5 r cc s e t 0x4000 SYSCFG 10 e : enable6 stm32f407xx gpio : Time i s 8 GPIOA PA5: wr i t e va lue 07 stm32f407xx gpio : Time i s 8 GPIOA PA6: wr i t e va lue 08 stm32f407xx gpio : Time i s 8 GPIOA PA9: wr i t e va lue 09 stm32f407xx gpio : Time i s 8 GPIOA PA10 : wr i t e va lue 0

10 stm32f407xx gpio : Time i s 8 GPIOA PA11 : wr i t e va lue 011 stm32f407xx gpio : Time i s 0 GPIOE PE12 : wr i t e va lue 012 stm32f407xx gpio : Time i s 0 GPIOE PE13 : wr i t e va lue 013 stm32f407xx gpio : GPIOE PE0 : mode s e t to Analog14 stm32f407xx gpio : GPIOE PE1 : mode s e t to Analog15 stm32f407xx gpio : GPIOE PE2 : mode s e t to Analog16 stm32f407xx gpio : GPIOE PE3 : mode s e t to Analog17 stm32f407xx gpio : GPIOE PE4 : mode s e t to Analog18 stm32f407xx gpio : GPIOE PE5 : mode s e t to Analog19 stm32f407xx gpio : GPIOE PE6 : mode s e t to Analog20 stm32f407xx gpio : GPIOE PE7 : mode s e t to Analog21 stm32f407xx gpio : GPIOE PE8 : mode s e t to Analog22 stm32f407xx gpio : GPIOE PE9 : mode s e t to Analog23 stm32f407xx gpio : GPIOE PE10 : mode s e t to Analog24 stm32f407xx gpio : GPIOE PE11 : mode s e t to Analog25 stm32f407xx gpio : GPIOE PE14 : mode s e t to Analog26 stm32f407xx gpio : GPIOE PE15 : mode s e t to Analog27 stm32f407xx gpio : GPIOC PC0 : mode s e t to Analog28 stm32f407xx gpio : GPIOC PC1 : mode s e t to Analog29 stm32f407xx gpio : GPIOC PC2 : mode s e t to Analog30 stm32f407xx gpio : GPIOC PC3 : mode s e t to Analog31 stm32f407xx gpio : GPIOC PC4 : mode s e t to Analog32 stm32f407xx gpio : GPIOC PC5 : mode s e t to Analog33 stm32f407xx gpio : GPIOC PC6 : mode s e t to Analog34 stm32f407xx gpio : GPIOC PC7 : mode s e t to Analog35 stm32f407xx gpio : GPIOC PC8 : mode s e t to Analog36 stm32f407xx gpio : GPIOC PC9 : mode s e t to Analog37 stm32f407xx gpio : GPIOC PC10 : mode s e t to Analog38 stm32f407xx gpio : GPIOC PC11 : mode s e t to Analog39 stm32f407xx gpio : GPIOC PC12 : mode s e t to Analog40 stm32f407xx gpio : GPIOC PC13 : mode s e t to Analog41 stm32f407xx gpio : GPIOC PC14 : mode s e t to Analog42 stm32f407xx gpio : GPIOC PC15 : mode s e t to Analog43 stm32f407xx gpio : GPIOA PA0: mode s e t to Analog44 stm32f407xx gpio : GPIOA PA1: mode s e t to Analog45 stm32f407xx gpio : GPIOA PA2: mode s e t to Analog46 stm32f407xx gpio : GPIOA PA3: mode s e t to Analog47 stm32f407xx gpio : GPIOA PA4: mode s e t to Analog



48 stm32f407xx gpio : GPIOA PA7: mode s e t to Analog49 stm32f407xx gpio : GPIOA PA8: mode s e t to Analog50 stm32f407xx gpio : GPIOA PA13 : mode s e t to Analog51 stm32f407xx gpio : GPIOA PA13 : pu/pd s e t to : No pul lup / pulldown52 stm32f407xx gpio : GPIOA PA14 : mode s e t to Analog53 stm32f407xx gpio : GPIOA PA14 : pu/pd s e t to : No pul lup / pulldown54 stm32f407xx gpio : GPIOA PA15 : mode s e t to Analog55 stm32f407xx gpio : GPIOA PA15 : pu/pd s e t to : No pul lup / pulldown56 stm32f407xx gpio : GPIOA PA5: mode s e t to Output57 stm32f407xx gpio : GPIOA PA6: mode s e t to Output58 stm32f407xx gpio : GPIOA PA9: mode s e t to Output59 stm32f407xx gpio : GPIOA PA10 : mode s e t to Output60 stm32f407xx gpio : GPIOA PA11 : mode s e t to Output61 stm32f407xx gpio : GPIOB PB0 : mode s e t to Analog62 stm32f407xx gpio : GPIOB PB1 : mode s e t to Analog63 stm32f407xx gpio : GPIOB PB2 : mode s e t to Analog64 stm32f407xx gpio : GPIOB PB3 : mode s e t to Analog65 stm32f407xx gpio : GPIOB PB4 : mode s e t to Analog66 stm32f407xx gpio : GPIOB PB4 : pu/pd s e t to : No pul lup / pulldown67 stm32f407xx gpio : GPIOB PB5 : mode s e t to Analog68 stm32f407xx gpio : GPIOB PB6 : mode s e t to Analog69 stm32f407xx gpio : GPIOB PB7 : mode s e t to Analog70 stm32f407xx gpio : GPIOB PB8 : mode s e t to Analog71 stm32f407xx gpio : GPIOB PB9 : mode s e t to Analog72 stm32f407xx gpio : GPIOB PB10 : mode s e t to Analog73 stm32f407xx gpio : GPIOB PB11 : mode s e t to Analog74 stm32f407xx gpio : GPIOB PB12 : mode s e t to Analog75 stm32f407xx gpio : GPIOB PB13 : mode s e t to Analog76 stm32f407xx gpio : GPIOB PB14 : mode s e t to Analog77 stm32f407xx gpio : GPIOB PB15 : mode s e t to Analog78 stm32f407xx gpio : GPIOE PE12 : mode s e t to Output79 stm32f407xx gpio : GPIOE PE13 : mode s e t to Output80 stm32f407xx gpio : GPIOD PD0: mode s e t to Analog81 stm32f407xx gpio : GPIOD PD1: mode s e t to Analog82 stm32f407xx gpio : GPIOD PD2: mode s e t to Analog83 stm32f407xx gpio : GPIOD PD3: mode s e t to Analog84 stm32f407xx gpio : GPIOD PD4: mode s e t to Analog85 stm32f407xx gpio : GPIOD PD5: mode s e t to Analog86 stm32f407xx gpio : GPIOD PD6: mode s e t to Analog87 stm32f407xx gpio : GPIOD PD7: mode s e t to Analog88 stm32f407xx gpio : GPIOD PD8: mode s e t to Analog89 stm32f407xx gpio : GPIOD PD9: mode s e t to Analog90 stm32f407xx gpio : GPIOD PD10 : mode s e t to Analog91 stm32f407xx gpio : GPIOD PD11 : mode s e t to Analog92 stm32f407xx gpio : GPIOD PD12 : mode s e t to Analog93 stm32f407xx gpio : GPIOD PD13 : mode s e t to Analog94 stm32f407xx gpio : GPIOD PD14 : mode s e t to Analog95 stm32f407xx gpio : GPIOD PD15 : mode s e t to Analog96 stm32f407xx gpio : Time i s 0 GPIOA PA6: wr i t e va lue 197 stm32f407xx gpio : Time i s 110 GPIOE PE12 : wr i t e va lue 198 stm32f407xx gpio : Time i s 104 GPIOA PA6: wr i t e va lue 099 stm32f407xx gpio : Time i s 106 GPIOE PE12 : wr i t e va lue 0

100 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 1101 stm32f407xx gpio : Time i s 104 GPIOE PE12 : wr i t e va lue 1102 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 0103 stm32f407xx gpio : Time i s 100 GPIOE PE12 : wr i t e va lue 0104 stm32f407xx gpio : Time i s 105 GPIOA PA6: wr i t e va lue 1105 stm32f407xx gpio : Time i s 100 GPIOE PE12 : wr i t e va lue 1106 stm32f407xx gpio : Time i s 107 GPIOA PA6: wr i t e va lue 0107 stm32f407xx gpio : Time i s 100 GPIOE PE12 : wr i t e va lue 0108 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 1109 stm32f407xx gpio : Time i s 104 GPIOE PE12 : wr i t e va lue 1110 stm32f407xx gpio : Time i s 101 GPIOA PA6: wr i t e va lue 0111 stm32f407xx gpio : Time i s 104 GPIOE PE12 : wr i t e va lue 0112 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 1113 stm32f407xx gpio : Time i s 100 GPIOE PE12 : wr i t e va lue 1114 stm32f407xx gpio : Time i s 108 GPIOA PA6: wr i t e va lue 0



115 stm32f407xx gpio : Time i s 101 GPIOE PE12 : wr i t e va lue 0116 stm32f407xx gpio : Time i s 104 GPIOA PA6: wr i t e va lue 1117 stm32f407xx gpio : Time i s 100 GPIOE PE12 : wr i t e va lue 1118 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 0119 stm32f407xx gpio : Time i s 108 GPIOE PE12 : wr i t e va lue 0120 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 1121 stm32f407xx gpio : Time i s 104 GPIOE PE12 : wr i t e va lue 1122 stm32f407xx gpio : Time i s 101 GPIOA PA6: wr i t e va lue 0123 stm32f407xx gpio : Time i s 100 GPIOE PE12 : wr i t e va lue 0124 stm32f407xx gpio : Time i s 104 GPIOA PA6: wr i t e va lue 1125 stm32f407xx gpio : Time i s 100 GPIOE PE12 : wr i t e va lue 1126 stm32f407xx gpio : Time i s 108 GPIOA PA6: wr i t e va lue 0127 stm32f407xx gpio : Time i s 101 GPIOE PE12 : wr i t e va lue 0128 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 1129 stm32f407xx gpio : Time i s 108 GPIOE PE12 : wr i t e va lue 1130 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 0131 stm32f407xx gpio : Time i s 108 GPIOE PE12 : wr i t e va lue 0132 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 1133 stm32f407xx gpio : Time i s 106 GPIOE PE12 : wr i t e va lue 1134 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 0135 stm32f407xx gpio : Time i s 100 GPIOE PE12 : wr i t e va lue 0136 stm32f407xx gpio : Time i s 104 GPIOA PA6: wr i t e va lue 1137 stm32f407xx gpio : Time i s 100 GPIOE PE12 : wr i t e va lue 1138 stm32f407xx gpio : Time i s 101 GPIOA PA6: wr i t e va lue 0139 stm32f407xx gpio : Time i s 107 GPIOE PE12 : wr i t e va lue 0140 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 1141 stm32f407xx gpio : Time i s 105 GPIOE PE12 : wr i t e va lue 1142 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 0143 stm32f407xx gpio : Time i s 100 GPIOE PE12 : wr i t e va lue 0144 stm32f407xx gpio : Time i s 109 GPIOA PA6: wr i t e va lue 1145 stm32f407xx gpio : Time i s 100 GPIOE PE12 : wr i t e va lue 1146 stm32f407xx gpio : Time i s 107 GPIOA PA6: wr i t e va lue 0147 stm32f407xx gpio : Time i s 100 GPIOE PE12 : wr i t e va lue 0148 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 1149 stm32f407xx gpio : Time i s 104 GPIOE PE12 : wr i t e va lue 1150 stm32f407xx gpio : Time i s 101 GPIOA PA6: wr i t e va lue 0151 stm32f407xx gpio : Time i s 108 GPIOE PE12 : wr i t e va lue 0152 stm32f407xx gpio : Time i s 100 GPIOA PA6: wr i t e va lue 1153 stm32f407xx gpio : Time i s 105 GPIOE PE12 : wr i t e va lue 1


1 sups@sups−Insp i ron −3421:˜/ Downloads$ qemu−system−arm −machine stm32f407ve scu −ke rne l t e s t 4 . b inary

2 STM32F2407 RCC : Cortex SYSTICK frequency s e t to 16000000 Hz .3 r cc s e t 0x0 SYSCFG 10 e : d i s a b l e4 r cc s e t 0x4000 SYSCFG 10 e : enable5 stm32f407xx gpio : Time i s 17 GPIOA PA5: wr i t e va lue 06 stm32f407xx gpio : Time i s 17 GPIOA PA6: wr i t e va lue 07 stm32f407xx gpio : Time i s 17 GPIOA PA9: wr i t e va lue 08 stm32f407xx gpio : Time i s 17 GPIOA PA10 : wr i t e va lue 09 stm32f407xx gpio : Time i s 17 GPIOA PA11 : wr i t e va lue 0

10 stm32f407xx gpio : Time i s 1 GPIOE PE12 : wr i t e va lue 011 stm32f407xx gpio : Time i s 1 GPIOE PE13 : wr i t e va lue 012 stm32f407xx gpio : GPIOE PE0 : mode s e t to Analog13 stm32f407xx gpio : GPIOE PE1 : mode s e t to Analog14 stm32f407xx gpio : GPIOE PE2 : mode s e t to Analog15 stm32f407xx gpio : GPIOE PE3 : mode s e t to Analog16 stm32f407xx gpio : GPIOE PE4 : mode s e t to Analog17 stm32f407xx gpio : GPIOE PE5 : mode s e t to Analog18 stm32f407xx gpio : GPIOE PE6 : mode s e t to Analog19 stm32f407xx gpio : GPIOE PE7 : mode s e t to Analog20 stm32f407xx gpio : GPIOE PE8 : mode s e t to Analog21 stm32f407xx gpio : GPIOE PE9 : mode s e t to Analog22 stm32f407xx gpio : GPIOE PE10 : mode s e t to Analog23 stm32f407xx gpio : GPIOE PE11 : mode s e t to Analog24 stm32f407xx gpio : GPIOE PE14 : mode s e t to Analog



25 stm32f407xx gpio : GPIOE PE15 : mode s e t to Analog26 stm32f407xx gpio : GPIOC PC0 : mode s e t to Analog27 stm32f407xx gpio : GPIOC PC1 : mode s e t to Analog28 stm32f407xx gpio : GPIOC PC2 : mode s e t to Analog29 stm32f407xx gpio : GPIOC PC3 : mode s e t to Analog30 stm32f407xx gpio : GPIOC PC4 : mode s e t to Analog31 stm32f407xx gpio : GPIOC PC5 : mode s e t to Analog32 stm32f407xx gpio : GPIOC PC6 : mode s e t to Analog33 stm32f407xx gpio : GPIOC PC7 : mode s e t to Analog34 stm32f407xx gpio : GPIOC PC8 : mode s e t to Analog35 stm32f407xx gpio : GPIOC PC9 : mode s e t to Analog36 stm32f407xx gpio : GPIOC PC10 : mode s e t to Analog37 stm32f407xx gpio : GPIOC PC11 : mode s e t to Analog38 stm32f407xx gpio : GPIOC PC12 : mode s e t to Analog39 stm32f407xx gpio : GPIOC PC13 : mode s e t to Analog40 stm32f407xx gpio : GPIOC PC14 : mode s e t to Analog41 stm32f407xx gpio : GPIOC PC15 : mode s e t to Analog42 stm32f407xx gpio : GPIOA PA0: mode s e t to Analog43 stm32f407xx gpio : GPIOA PA1: mode s e t to Analog44 stm32f407xx gpio : GPIOA PA2: mode s e t to Analog45 stm32f407xx gpio : GPIOA PA3: mode s e t to Analog46 stm32f407xx gpio : GPIOA PA4: mode s e t to Analog47 stm32f407xx gpio : GPIOA PA7: mode s e t to Analog48 stm32f407xx gpio : GPIOA PA8: mode s e t to Analog49 stm32f407xx gpio : GPIOA PA13 : mode s e t to Analog50 stm32f407xx gpio : GPIOA PA13 : pu/pd s e t to : No pul lup / pulldown51 stm32f407xx gpio : GPIOA PA14 : mode s e t to Analog52 stm32f407xx gpio : GPIOA PA14 : pu/pd s e t to : No pul lup / pulldown53 stm32f407xx gpio : GPIOA PA15 : mode s e t to Analog54 stm32f407xx gpio : GPIOA PA15 : pu/pd s e t to : No pul lup / pulldown55 stm32f407xx gpio : GPIOA PA5: mode s e t to Output56 stm32f407xx gpio : GPIOA PA6: mode s e t to Output57 stm32f407xx gpio : GPIOA PA9: mode s e t to Output58 stm32f407xx gpio : GPIOA PA10 : mode s e t to Output59 stm32f407xx gpio : GPIOA PA11 : mode s e t to Output60 stm32f407xx gpio : GPIOB PB0 : mode s e t to Analog61 stm32f407xx gpio : GPIOB PB1 : mode s e t to Analog62 stm32f407xx gpio : GPIOB PB2 : mode s e t to Analog63 stm32f407xx gpio : GPIOB PB3 : mode s e t to Analog64 stm32f407xx gpio : GPIOB PB4 : mode s e t to Analog65 stm32f407xx gpio : GPIOB PB4 : pu/pd s e t to : No pul lup / pulldown66 stm32f407xx gpio : GPIOB PB5 : mode s e t to Analog67 stm32f407xx gpio : GPIOB PB6 : mode s e t to Analog68 stm32f407xx gpio : GPIOB PB7 : mode s e t to Analog69 stm32f407xx gpio : GPIOB PB8 : mode s e t to Analog70 stm32f407xx gpio : GPIOB PB9 : mode s e t to Analog71 stm32f407xx gpio : GPIOB PB10 : mode s e t to Analog72 stm32f407xx gpio : GPIOB PB11 : mode s e t to Analog73 stm32f407xx gpio : GPIOB PB12 : mode s e t to Analog74 stm32f407xx gpio : GPIOB PB13 : mode s e t to Analog75 stm32f407xx gpio : GPIOB PB14 : mode s e t to Analog76 stm32f407xx gpio : GPIOB PB15 : mode s e t to Analog77 stm32f407xx gpio : GPIOE PE12 : mode s e t to Output78 stm32f407xx gpio : GPIOE PE13 : mode s e t to Output79 stm32f407xx gpio : GPIOD PD0: mode s e t to Analog80 stm32f407xx gpio : GPIOD PD1: mode s e t to Analog81 stm32f407xx gpio : GPIOD PD2: mode s e t to Analog82 stm32f407xx gpio : GPIOD PD3: mode s e t to Analog83 stm32f407xx gpio : GPIOD PD4: mode s e t to Analog84 stm32f407xx gpio : GPIOD PD5: mode s e t to Analog85 stm32f407xx gpio : GPIOD PD6: mode s e t to Analog86 stm32f407xx gpio : GPIOD PD7: mode s e t to Analog87 stm32f407xx gpio : GPIOD PD8: mode s e t to Analog88 stm32f407xx gpio : GPIOD PD9: mode s e t to Analog89 stm32f407xx gpio : GPIOD PD10 : mode s e t to Analog90 stm32f407xx gpio : GPIOD PD11 : mode s e t to Analog91 stm32f407xx gpio : GPIOD PD12 : mode s e t to Analog



92 stm32f407xx gpio : GPIOD PD13 : mode s e t to Analog93 stm32f407xx gpio : GPIOD PD14 : mode s e t to Analog94 stm32f407xx gpio : GPIOD PD15 : mode s e t to Analog95 stm32f407xx gpio : Time i s 3054 GPIOA PA9: wr i t e va lue 196 stm32f407xx gpio : Time i s 2057 GPIOA PA9: wr i t e va lue 097 stm32f407xx gpio : Time i s 1012 GPIOA PA9: wr i t e va lue 198 stm32f407xx gpio : Time i s 1019 GPIOA PA9: wr i t e va lue 099 stm32f407xx gpio : Time i s 1019 GPIOA PA9: wr i t e va lue 1

100 stm32f407xx gpio : Time i s 1011 GPIOA PA9: wr i t e va lue 0101 stm32f407xx gpio : Time i s 1022 GPIOA PA10 : wr i t e va lue 1102 stm32f407xx gpio : Time i s 3174 GPIOA PA9: wr i t e va lue 1103 stm32f407xx gpio : Time i s 2025 GPIOA PA9: wr i t e va lue 0104 stm32f407xx gpio : Time i s 1016 GPIOA PA9: wr i t e va lue 1105 stm32f407xx gpio : Time i s 1012 GPIOA PA9: wr i t e va lue 0106 stm32f407xx gpio : Time i s 1017 GPIOA PA9: wr i t e va lue 1107 stm32f407xx gpio : Time i s 1011 GPIOA PA9: wr i t e va lue 0108 stm32f407xx gpio : Time i s 1012 GPIOA PA10 : wr i t e va lue 0109 stm32f407xx gpio : Time i s 3037 GPIOA PA9: wr i t e va lue 1110 stm32f407xx gpio : Time i s 2036 GPIOA PA9: wr i t e va lue 0111 stm32f407xx gpio : Time i s 1011 GPIOA PA9: wr i t e va lue 1112 stm32f407xx gpio : Time i s 1017 GPIOA PA9: wr i t e va lue 0113 stm32f407xx gpio : Time i s 1043 GPIOA PA9: wr i t e va lue 1114 stm32f407xx gpio : Time i s 1016 GPIOA PA9: wr i t e va lue 0115 stm32f407xx gpio : Time i s 1013 GPIOA PA10 : wr i t e va lue 1116 stm32f407xx gpio : Time i s 3043 GPIOA PA9: wr i t e va lue 1117 stm32f407xx gpio : Time i s 2034 GPIOA PA9: wr i t e va lue 0118 stm32f407xx gpio : Time i s 1008 GPIOA PA9: wr i t e va lue 1119 stm32f407xx gpio : Time i s 1016 GPIOA PA9: wr i t e va lue 0120 stm32f407xx gpio : Time i s 1017 GPIOA PA9: wr i t e va lue 1121 stm32f407xx gpio : Time i s 1014 GPIOA PA9: wr i t e va lue 0122 stm32f407xx gpio : Time i s 1014 GPIOA PA10 : wr i t e va lue 0123 stm32f407xx gpio : Time i s 3049 GPIOA PA9: wr i t e va lue 1124 stm32f407xx gpio : Time i s 2022 GPIOA PA9: wr i t e va lue 0125 stm32f407xx gpio : Time i s 1011 GPIOA PA9: wr i t e va lue 1126 stm32f407xx gpio : Time i s 1014 GPIOA PA9: wr i t e va lue 0127 stm32f407xx gpio : Time i s 1011 GPIOA PA9: wr i t e va lue 1128 stm32f407xx gpio : Time i s 1014 GPIOA PA9: wr i t e va lue 0129 stm32f407xx gpio : Time i s 1022 GPIOA PA10 : wr i t e va lue 1130 stm32f407xx gpio : Time i s 3052 GPIOA PA9: wr i t e va lue 1131 stm32f407xx gpio : Time i s 2047 GPIOA PA9: wr i t e va lue 0132 stm32f407xx gpio : Time i s 1016 GPIOA PA9: wr i t e va lue 1133 stm32f407xx gpio : Time i s 1010 GPIOA PA9: wr i t e va lue 0134 stm32f407xx gpio : Time i s 1023 GPIOA PA9: wr i t e va lue 1135 stm32f407xx gpio : Time i s 1018 GPIOA PA9: wr i t e va lue 0136 stm32f407xx gpio : Time i s 1013 GPIOA PA10 : wr i t e va lue 0137 stm32f407xx gpio : Time i s 3074 GPIOA PA9: wr i t e va lue 1138 stm32f407xx gpio : Time i s 2031 GPIOA PA9: wr i t e va lue 0

