Android hardware-software design using virtual prototypes - Part 2: Building a sensor subsystem -

Android hardware-software design using virtual prototypes – Part 2: Building a sensor subsystem

Editor’s Note: In the second of a three-part series of articles on virtual prototyping, Achim Nohl explains how to use the Synopsys Virtualizer Development Kit (VDK) and describes the hardware/software integration flow for a sensor subsystem for use in an Android mobile device.

For the remainder of this series, we will illustrate virtual prototyping usage and early software development by means of a brief case study. The case study is centered on a multi-function sensor controller subsystem which supports an accelerometer, magnetic field, orientation, gyroscope, light, pressure, temperature, and proximity.

The subsystem embeds an ARM Cortex- M3 microcontroller along with generic peripherals such as an interrupt controller, memories, GPIOs, and I2C. The sensor subsystem runs dedicated firmware to proxy the requested sensor data into a shared memory mailbox for communication with the main CPU. The main CPU, an ARM Cortex-A series CPU, runs Linux and Android.

The full integration of the sensor through multiple subsystems and multiple software layers creates challenges for the responsible software developers, as shown in Figure 4 .

Click on image to enlarge.

Figure 4 – Sensor Software Integration

In the following sections, we will introduce how virtual prototyping helps to address those challenges. We will go bottom up and start with the sensor firmware development up to the usage in Android applications.

Creating a sensor subsystem virtual prototype
In order to develop firmware for the sensor controller subsystem prior to RTL being available, a standalone subsystem virtual prototype (VP) will be created. This means the VP will initially not be integrated into an application platform and solely used for the subsystem firmware. The main subsystem parts, memory map and interrupt configuration is defined as follows:

Click on image to enlarge.

Using this specification, the subsystem VP can be created using the Virtualizer authoring GUI, as shown in Figure 5 . The author selects the necessary models from the processor and peripheral model library which is shown on the left hand side of the tools. The connectivity of the reset, clock and interrupt lines can be performed graphically as well as the specification of the memory map. Each bus slave in the platform, such as the peripherals, can be equipped with a target address.

Click on image to enlarge.

Figure 5 – Sensor Subsystem Assembly

If all models do exist, a VP can be created in a few minutes. As an alternative, the VP can be assembled using a TCL-based scripting interface. Therefore, each action in the GUI corresponds to a TCL command. The user can generate a batch mode authoring script by recording the commands, which are issued during the GUI based assembly.

Later on, the script is a perfect vehicle to create and maintain platform variants with different memory maps, interrupts, etc. Scripting is a much more scalable approach than maintaining many platform variants using a GUI. The script needed to create the sensor subsystem contains ~150 lines including comments. Once the platform is ready, the VP can be compiled and is ready to be used by the software developer.

Sensor subsystem firmware development
The sensor firmwarecommunicates with the Linux sensor device driver via a so-called InterProcessor Communication Module (IPCM). This peripheral is located in ashared memory region and is accessible from the main CPU and theembedded controller. The IPCM can send out notifications throughinterrupts when a new message for the main CPU or the controller hasarrived. For this purpose, the IPCM contains some control registers thatallow the sending processor to notify the receiving processor. Thesensor subsystem controller firmware receives commands such as “readaccelerometer” from the main CPU. Therefore, the main CPU writes therequired command ID into the IPCM and notifies the controller. Thecontroller interrupt handler wakes up, reads out the command from theIPCM, determines the sensor value from the GPIOs/I2C, and provides thedata back into the IPCM. The firmware for the ARM Cortex-M3microcontroller can be developed using a standard tool chain such asGCC, DS-5/RVDS. The resulting binary image can be loaded directly intothe memories using the VP tool infrastructure. Afterwards, the softwaredeveloper can use his favorite debug tool along with the embeddedcontroller CPU as shown in Figure 6 .

Click on image to enlarge.

Figure 6 – Using standard Lauterbach TRACE32 for software debugging on a VP

AVP integrates a debug server that manages the connection to 3rd partydebuggers such as gdb, Lauterbach TRACE32 and ARM’s DS-5. In a multicoresystem, even multiple debuggers can be connected in parallel. Theconnection is performed in the previously introduced stop-mode. When thedebugger suspends the simulation, the entire simulation is halted andnot just the core. Thus, no watchdogs expire or interrupts executedduring the period of suspension. This mode enables repeatable debuggingdue to the fact that debugging is non-intrusive and thereforedeterministic.

Beyond what a debugger exposes, the VP complementsthe software debugger with extra visibility into the systemperipherals, their registers, and signals as shown in Figure 7 .

Click on image to enlarge.

Figure 7 – Virtual Prototype Analyzer

Thisextra visibility is helpful for any kind of low-level softwaredevelopment where large parts of the software program's peripheralregisters react to interrupts etc. A VP also allows setting watchpointson system aspects (e.g. signals) which are typically not visible to thesoftware developer, making it possible to set a watchpoint on theinterrupt line of the IPCM. Thus, the interrupt handler debugging can bestarted before the CPU even enters the interrupt vector. Wrongly maskedinterrupts are much easier to debug with this level of control.

Achallenge with firmware development for a subsystem is typically theinteraction with the main CPU and the off-chip interfaces. Since thefirmware needs to react based on commands from the Linux driver runningon the main CPU and needs to deliver data received via GPIO, it is hardto validate the firmware without having this interaction. A VP providessome helpful capabilities in this case. Through a TCL-based scriptinginterface, the user can poke data into the IPCM, GPIO, and/or I2C atdefined points in time. Thus, the VP user can easily createdeterministic and repeatable test and debug scenarios that simulate theexternal environment without bringing up the main CPU Linux and drivers.This way of debugging facilitates firmware bring-up since no additionalcomplexity is introduced and also reduces testing complexity. All unittests for the sensor subsystem can be executed in isolation withoutintroducing potential fault sources through the main CPU, Linux OS ordrivers etc.

Linux driver development for the sensor subsystem
Asa next step, the Linux device driver will need to be developed. ThisLinux driver allows the upper Android software layers to query data fromthe sensor. The driver itself will communicate with the sensor firmwareof the subsystem through the shared IPCM. Since Linux runs on anapplication CPU such as the ARM Cortex-A9MP core, a platform that issufficiently equipped with the CPU and peripherals is needed. For thisreference platform, we have chosen the VDK for the ARM Versatile Expresssystem as a development vehicle for our Linux driver. Here, we canreuse the Android and Linux configurations, which are available fromcommunities such as Linaro. This makes it easy to get Linux and Androidup and running, which is needed to start our driver development for thesensor controller subsystem. For this purpose, the sensor controllersubsystem will be integrated into the VDK as a “LogicTile” virtualdaughterboard. Similar to the hardware, the VDK provides an easymechanism to configure the CPU and the daughterboards, as shown in Figure 8 .

Click on image to enlarge.

Figure 8 – VDK Customization

Thedaughterboard will be configured with the address of the IPCM in theshared memory space as well as the interrupt lines between the IPCM andthe Vectored Interrupt Controller used by the Cortex-A9 CPU. After theconfiguration, the software developer is able to build a multicore VPthat embeds the Cortex-A9 application processor as well as the Cortex-M3based sensor control subsystem.

The driver for the sensor usesthe “syssfs” pseudo file system to expose the data from the sensor tothe user space (Linux applications/middleware). The code for updating asensor value does prepare the IPCM with the required request command,sends the message, then the driver waits for the acknowledgment of thesensor control subsystem. The acknowledge flag is set in the driver’sinterrupt handler so the kernel can schedule other tasks while waitingfor the data. In order to ease debugging, kernel debug messages (printk)have been placed in between the lines as shown below:

Click on image to enlarge.

Example 1 – Sensor Driver Code Excerpt

Whenlaunching the VDK, the user is able to interact with the system througha VGA framebuffer console which is connected to the VDK’s color LCDcontroller, keyboard and mouse interfaces. As shown in Figure 9, thesoftware developer can issue commands such as reading out the sensorvalues through the Linux kernel “syssfs” pseudo file system. The twoconsole terminals visualize the debug messages that are coming from thesensor subsystem, as well as from the Linux kernel.

Click on image to enlarge.

Figure 9 – Sensor device driver testing

Ina VP, the number of UARTs is unlimited, which is helpful whenintegrating many software entities and their layers, but also introducesthe challenge of understanding the sequencing of the different debugmessages. Messages from the sensor control versus messages from the interacting sensor driver require separate analysis in the order in which they occur within the system. The ability to track the sequence of events is supported by the built-in tracing infrastructure of a VP.

All debug messages are consolidated into a single data base, illustrated in Figure 10 .The first two rows in the system analysis view visualize the points intime at which debug messages are issued from the driver and the sensorby drawing dots on the timeline. Each dot corresponds to a debug messagethat is exposed in the bottom area of the windows, displaying exactlywhen and in which order the messages are issued. This can be helpfulwhen integrating and debugging multiple software entities that operatein parallel, such as in our example.

Click on image to enlarge.

Figure 10 – System Tracing

Buteven more visibility is provided by a VP. The IPCM interrupts betweenthe main CPU and the controller can be traced along with the accesses tothe shared IPCM registers. Next to that, the function trace of each CPUcan be obtained. This allows for a successive top down debug flow forparallel software integration. A bird’s eye view allows for a quickassessment of the situation, in addition to the ability to drill deeper,uncovering more information and ultimately identifying the singleinstruction that accesses a register. This level of visibility is acrucial capability when dealing with low level software, especially onmulticore systems.

A software debugger can be connected for Linuxdriver debugging in the same way (stop mode) as done in the previoussection for the sensor control subsystem bare metal firmware. There isno need to setup support for a kernel debugger (kdb) or similar. Theconnectivity is established out of the box through the VP debug server,which is Linux thread aware for thread level debugging. We will furtherdescribe this next In Part 3 in this series on how to use Android’sHardware Abstraction Layer to aid in integrating the sensor further upthe device software stack.

Part 1: Why virtualize
Part 3: Integrating Android’s HAL

Achim Nohl  isa technical marketing manager for Virtual Prototypes at Synopsys. Heactively publishes technical articles, conference papers, and blog postsaround the topic of developing embedded software using virtualprototypes. His specialty is bringing up firmware, drivers, andoperating systems for the most recent CPUs and IPs. Achim holds a degreein Electrical Engineering from the Institute for Integrated SignalProcessing Systems at the Aachen University of Technology, Germany.Before joining Synopsys, Achim has worked in various engineering andmarketing roles for LISATek and CoWare.

1. Android SDK
2. Qemu
3. ARM Versatile Express
4. Linaro
5. HAPS Family of FPGA-Based Prototyping Solutions
6. Virtualizer
8. Virtual Prototype Creation and Development Kits

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.