Debugging is a key part of software development and is often considered to be the most time-consuming, and therefore expensive, part of the process. It enables software developers to create applications, middleware, and platform software that meets the three key criteria of high performance, lower power consumption, and reliability. However, bugs can be difficult to detect, reproduce, and fix. It can also be difficult to predict the length of time required to resolve a defect. The cost of resolving problems grows significantly when the product is delivered to a customer. In many cases, when a product has a small time window for sales, if the product is late, it can miss the market opportunity. Therefore, the debug facilities provided by a system are a vital consideration for any developer.
Many embedded systems using ARM processors have limited input/output
facilities. This means that traditional desktop debug methods (such
as use of
printf()) might not be appropriate.
In such systems in the past, developers might have used expensive
hardware tools like logic analyzers or oscilloscopes to observe
the behavior of programs. The processors described in this book
are part of a complex System-on-Chip (SoC) containing memory, caches, and
many other blocks. There might be no processor signals that are
visible off-chip and therefore no ability to monitor behavior by
connecting up a logic analyzer (or similar). For this reason, ARM
systems typically include dedicated hardware to provide wide-ranging
control and observation facilities for debug.
External debug features were first introduced on ARMv4 architecture processors to support developers using embedded and deeply embedded processors, and have evolved into a broad portfolio of debug and trace features. Support for rich application software platforms, in particular, support for self-hosted debug and performance profiling, has been a more recent addition in the ARMv6 and ARMv7-A architectures.
ARMv8 processors provide hardware features that enable debug tools to provide significant levels of control over core activity and to non-invasively collect large amounts of data about program execution. There are two broad classes of hardware features, invasive and non-invasive.