Static checking of interrupt-driven software

Abstract

Resource-constrained devices are becoming ubiquitous. Examples include cell phones, palm pilots, and digital thermostats. It can be difficult to fit required functionality into such a device without sacrificing the simplicity and clarity of the software. Increasingly complex embedded systems require extensive brute-force testing, making development and maintenance costly. This is particularly true for system components that are written in assembly language. Static checking has the potential of alleviating these problems, but until now there has been little tool support for programming at the assembly level.In this paper we present the design and implementation of a static checker for interrupt-driven Z86-based software with hard real-time requiremeng. For six commercial microcontrollers, our checker has produced upper bounds on interrupt latencies and stack sizes, as well as verified fundamental safety and liveness properties. Our approachis based on a known algorithm for model checking of pushdown systems, and produces a control-flow graph annotated with information about time, space, safety, and liveness. Each benchmark is approximately loo0 lines of code, and the checking is done in a'few seconds on a standard PC. Our tool is one of the first to give an efficient and useful static analysis of assembly code. It enables increased confidence in correctness, significantly reduced testing requirements, and support for maintenance throughout the system life-cycle.

Model checking interrupt-dependent software

“…Closest of all to our research was the development of a model checking tool for software running on the Z86 processor [5]. As in our work, the emphasis was on interruptdependent programs written in assembly code.…”

Eliminating the call stack to save RAM

“…Estimating the worst-case stack memory usage of a program is not totally straightforward, but the problem has been previously addressed [Brylow et al 2001, McCartney and Sridhar 2006, Regehr et al 2003]. Our approach to bounding stack memory consumption is based on this previous work: we have a program that walks the callgraphs of an AVR binary, conservatively estimating the worstcase stack depth of each function as it is found.…”

“…This permits developers to avoid a difficult problem: predicting worst-case stack memory usage. Another way to avoid this problem is to use a static analysis tool [Brylow et al 2001, McCartney and Sridhar 2006, Regehr et al 2003]. However, for various reasons these tools are not in widespread use and in practice developers rely on guesswork [Ganssle 1999].…”

Safe and Structured Use of Interrupts in Real-Time and Embedded Software

“…AbsInt sells a standalone stack depth analysis tool called StackAnalyzer [1]. The only tools that we know of that analyze stack depth in the presence of interrupts are ours [16] and Brylow et al's [5]. In related work, Barua et al [3] investigate an approach that, upon detecting stack overflow, spills the stack data into an unused region of RAM, if one is available.…”