4 - System debugging strategies

Summary

Introduction

Debugging embedded software is harder than debugging programs on a PC. In general purpose software, our overriding goal is functionality or input–output behavior. Embedded systems have different and more stringent design goals than business or scientific software. Functional correctness is still a given, but it is only the first of many requirements placed on the system. These goals make embedded system debugging a very different problem.

First, embedded systems must meet real-time performance goals. Almost meeting the deadline doesn't count – a task must finish all its work by its deadline. Debugging a program for performance requires a different set of tools than is used for functional debugging. Real-time debugging is closely related to the underlying hardware architecture on which the program will execute, and so is much more closely tied to the platform than is functional debugging.

Second, many embedded systems are power and energy limited. Even embedded processors that are not powered by a battery are generally designed to power budgets to reduce heat dissipation and system cost. Like real-time performance, power and energy consumption are closely related to the hardware platform and require very different tools.

In both these cases, the characteristics and organization of the hardware platform are important determinants of the program characteristics that we want to measure and debug. When debugging programs for workstations, most of the platform dependencies that we care about come from the operating system and associated libraries. Most programmers don't worry about, for example, the details of the memory system.