RTC Magazine

Choosing a CPU for an embedded product is tricky. The team set with the task of choosing a target architecture must ask a number of important questions. How fast does it need to be? How much power will it consume? How much memory does the application require? Most teams will consider these issues in the process of choosing their target architecture.

None of these questions, however, addresses the efficiency of the most expensive phase of building your product—the software development. Software problems can cost days, weeks or months on your schedule. Engineering time is expensive. Combining a target architecture with advanced on-chip debugging features, a hardware debug device capable of moving and analyzing data quickly and accurately, and a feature-rich debugger will create a debug environment that will shorten your time-to-market.

Bare-Bones Application Debugging

A CPU that provides nothing in the way of on-chip debugging features paired with a basic hardware interface (usually a serial cable) does very little to aid your host-side debugger. The shortcomings of this arrangement allow only primitive methods or force the developer to seek creative tricks. In the simplest case, you can instrument your code to light an LED on your hardware when a specific condition arises. If you have a serial port with a working driver, it can be used to transmit data to the development host.

A debug monitor may be employed to provide run control capability and access to memory, but because this is a program that runs in ROM it provides access to only a limited number of registers and utilizes valuable CPU time. Such a monitor may require the use of CPU capabilities needed by your own software. Because a debug monitor must be running at all times, it does not provide you with the option to completely halt your target to examine a problem. The monitor will also, of course, require use of your cache and other buffers, so debugging them will be impossible in this scenario.

It should be noted that some processors do allow for critical interrupt handlers to run concurrently with a debug monitor. Specifically, newer ARM, IBM PowerPC and ColdFire cores allow you to run critical interrupts in the background while still giving you access to all of their hardware debug features in the foreground. If your system relies on handlers that must run to prevent damage to your system, even while you are debugging, this feature will be important to you.

Some debugging environments use a pairing of code instrumentation with a data collection agent, implemented either in software or via a hardware device, typically a logic analyzer. In this instance, the chip must have an external bus for data collection and your target must have a port capable of transferring the data to the debugger, making primitive code profiling and coverage analysis possible. You can also use this technique to monitor the performance of your memory allocation system, enabling you to detect memory leaks or other allocation bugs.

All of these solutions require you to resort to the use of code instrumentation, which severely limits your ability to accurately assess the real-world performance of your final product. Additionally, when the instrumentation is removed, your system may be fundamentally changed. Subtle timing and memory bugs that appear at this stage are very difficult to diagnose.

Upgrading with On-Chip Debugging

With a less austere setup in which on-chip features provide you with run control over your chip, you gain the ability to collect information during the program’s execution. The program can be halted and information can be transported up to the development host for debugging purposes. This method does not require any code instrumentation, and because the data does not need to be stored on the target, a large amount of data can be collected.

It does, however, require the target to be halted for the information to be

collected, so that the system you are debugging is still not a fully accurate representation of your deployed system. Depending on your project requirements, this may or may not be acceptable. Code instrumentation will still be necessary if you want to collect profiling data. The data you gather will be more accurate than that available with a debug monitor, but it remains an instrumented system, with the associated disadvantages.