Debugging advanced mixed-signal microcontrollers

The 8-bit microcontroller has been the mainstay of embedded-control systems for nearly 20 years. Several popular architectures are available, the devices are available for a low cost, the instruction sets are easy to use, and many vendors offer a multitude of products. Despite the maturity of this market, vendors continue to develop innovative solutions based on 8-bit processors. The latest generation of 8-bit microcontrollers is breathing new life into established architectures by increasing performance, integration, and flexibility. With precision-analog, high-throughput processors, and in-system-programmable flash memory integrated on a single die, these devices are truly SOC (system-on-chip) products. SOC devices have many advantages, including lower system cost, reduced board space, and superior system performance and reliability.

Unfortunately, these advanced devices also give rise to a new set of challenges for the embedded-software-development and -debugging process. For complex systems, source-level software-development and -debugging tools are essential, but key to embedded-systems debugging is the link between the source view and the hardware. Although traditional embedded-development techniques have been adequate for relatively low-throughput controllers with few or no analog functions, these methods can be insufficient for the latest SOC products. In the 8-bit world, embedded-systems developers rely on three basic strategies for debugging: EPROM/OTP prototyping, target-monitor programs, and ICE (in-circuit-emulator) systems.

The most basic development method for embedded projects has historically been EPROM/OTP prototyping. In this scheme, the developer creates the software in assembler or C on a desktop PC and then programs EPROM, OTP, or EEPROM devices with the object code. The target device mounts on a prototype board with a device socket for debugging. The developer tests the system for proper functionality and corrects errors by modifying the source code, programming a new device, and mounting the new device in the socket to repeat the testing process.

In the past, this "burn-and-learn" approach to software development was a low-cost and effective method for software development. As the level of device integration and complexity increases, this process is quickly becoming unproductive for advanced mixed-signal devices that are incorporating more program memory, data memory, and processor performance in the controller. The prototype device offers little or no visibility into the inner workings of the system that can lengthen the code-program-test cycle and force the use of software hooks (such as toggling external pins) to monitor code execution and target behavior.

As applications become more complex, developers may have to pack more circuitry in a smaller form factor, making sockets impractical. To address system-space constraints, chip vendors offer high-pin-count, surface-mount packaging. But such devices are difficult to hand mount or rework on a pc board and make the EPROM-prototype approach impractical.

Including a software-monitor program in the target device addresses the visibility shortcomings of the EPROM-prototype approach. The target monitor communicates with a host-based debugger via a serial link and allows basic in-system run control of the target, such as run/stop, single-step, and software breakpoints. The target monitor implements software breakpoints by replacing instructions in the target device's program memory with a jump to the monitor program.

Although this approach allows developers to query the target device during runtime, it consumes resources in the target system to manage the serial link and command interface. A software monitor cannot debug ROM-based code using software breakpoints because the monitor must alter program memory to provide run control. When the monitor is an interrupt-driven software process, users cannot set breakpoints within interrupt-service routines. Interrupt routines can be a significant portion of the total program in complex embedded systems, so the inability to debug within interrupts is a serious constraint.

The top end of 8-bit development systems is the ICE. An ICE consists of an emulator pod that includes circuitry to exactly reproduce the behavior of the target device. The pod electrically replaces the controller in the target system via a cable/socket combination.

The main advantage of an ICE system is that it provides complete visibility of the inner workings of the target device. The developer can see precisely what the code is doing as it executes. Basic ICE systems provide emulation RAM for the target code and complex hardware breakpoint capabilities. Most ICE systems also include real-time trace capability, allowing pin-state and internal-variable captures for hundreds or even thousands of clock cycles. This capability is extremely useful for debugging complex real-time problems. ICE systems are nonintrusive from the software's point of view, because the emulator acts exactly as the true target.

These functions come at a price. Prices for ICE systems can range from several hundred to many thousands of dollars. As clock speeds increase, it becomes more difficult to specify a system that supports an ICE, because the cables and mechanical connections introduce extra signal delay. Particularly for advanced analog systems, the emulator cables become a serious consideration. Cable inductance, parasitic coupling, and interference conspire to make emulation of precision-analog circuits virtually impossible (Figure 1). As a result, developers of mixed-signal systems can use an ICE only for debugging the digital behavior and must wait until later in the design cycle to determine the true analog performance.

An ideal embedded development-and-debugging system provides a simple device-programming method, internal visibility of the target system, and real-time control—all at a reasonable cost (Table 1). The combination of in-system-programmable flash memory and on-chip dedicated debugging logic supports such a development environment. On-chip debugging provides nonintrusive real-time run control in hardware without consuming user resources, because the programmer/debugger has its own dedicated resources and interface. Debugging takes place in the target system and can use production devices in the target hardware. On-chip debugging is especially useful for precision-analog systems, because developers can evaluate the true analog performance of the complete system, including board layout and parasitic effects. Without an emulator pod, there are no additional cables, sockets, or probes to interfere with the analog performance supporting true debugging of analog subsystems in real time.

On-chip debugging systems are common in 32-bit controllers but uncommon in 8-bit architectures. The Cygnal Integrated Products (www.cygnal.com) C8051F series and Atmel (www.atmel.com) AVR devices with JTAG interfaces are 8-bit architectures that include built-in on-chip debugging logic. The on-chip logic on these devices uses a JTAG-based debugging interface (Figure 2), supports hardware breakpoints, and allows the user to inspect/modify memory locations, set/clear breakpoints, single-step, and modify flash. Production devices support the debugging and development in the user's target hardware with no emulation. The debugging logic ensures that the peripherals remain lock-stepped with the source view during debugging events, such as single-stepping, and allows debugging of interrupt-service routines.

As vendors offer higher throughput cores, more analog functions, and more on-chip memory, additional debugging support becomes essential. As system developers face shorter schedules and tighter budgets for more complex designs, they need controller vendors to provide systems that are simpler to use, more cost effective, and easier to debug. Ideally, an on-chip-debugging system will provide most of the features of an ICE system at a reduced cost, but a key element missing from this generation of on-chip-debugging hardware for 8-bit systems is real-time trace capability. Look for vendors to offer increasing levels of trace functions in the future, starting with real-time program-trace features. Using 32-bit controllers as a guide, some of the more advanced features of those on-chip-debugging systems, such as more hardware breakpoints, complex breakpoints, and conditional data breakpoints, should soon migrate to the 8-bit world.