Until recently, engineers have lived with a basic limitation of µP-board design: the inability to inspect or directly control the internal workings of the actual µP. This limitation was especially irritating when the core system crashed, rendering onboard diagnostic software unusable. Unable to run even the most rudimentary diagnostic software, engineers resorted to intelligent guesswork or used a costly in-circuit emulator (ICE).

To address this µP-access limitation, a new generation of µPs includes a background-debug mode that provides an independent port directly into the µP. Besides reducing the need for ICEs, background-debug mode can also streamline critical design and manufacturing tasks.

By incorporating a µP with background-debug mode into a design, you can directly perform a range of functions that previously required resources external to the µP. First and foremost, background-debug mode enables you to take a structured approach to design verification and debugging. Background-debug mode’s usefulness goes beyond troubleshooting to include a variety of applications that range from bringing up prototype boards to inspecting error logs during manufacturing and field servicing.

ICE limitations

ICEs are powerful tools for debugging and verifying µP-based designs. But, because emulators are expensive, project managers usually purchase only a few to share among a team of engineers.

ICEs have some severe limitations; and although they give you access to the inner workings of the µP, they introduce a new layer of complexity and cost for both design and manufacturing. Emulators can either create or mask µP problems. When a system failure occurs with an installed emulator, you must first determine if the emulator induced the failure or if the problem actually stemmed from a real flaw.

In addition, installing an emulator during verification or manufacturing may be difficult. Most problems at these stages are specific to a particular µP board or its µP, and not the design itself. So removing the µP and adding a socket for an emulator can subtly change the problem—or even make the problem magically disappear.

Background-debug-mode µPs

You can eliminate the need for ICEs by incorporating the new type of µP with background-debug mode. Using a background-debug-mode µP, you can directly monitor and interact with the µP at any stage of design or manufacturing without having to resort to an ICE. Fig 1 shows how a µP with background-debug mode simply monitors the traffic on the µP’s internal bus. In contrast, an ICE replaces the µP in the target system. Therefore, all of the µP’s external bus traffic must traverse the cable between the emulator and the target system, possibly altering timing or the system’s electrical characteristics.

To provide a window into the µP’s activities, the background-debug-mode µP contains a debugger in its microcode and a dedicated serial-debug port.

In a design with background-debug mode, you can view and alter the core µP system directly, including the µP’s internal registers, external RAM and EEPROM, and buses. The hardware and software requirements are simple and straightforward for background-debug mode. The physical link between a background-debug-mode µP and a controlling PC is a simple 2×5-pin connector mounted on the µP board (Fig 2).

The µP’s manufacturer supplies a special interface cable to connect to a PC along with software for communicating while in the background-debug mode.

The background-debug-mode software resident on the PC has the look and feel of ROM-resident debugger code. The software provides all of the expected debugging functions, such as modifying memory, downloading code, and starting execution. It can also use the PC’s serial port to send and receive synchronous serial data. Additional debugging capability is possible if you include a breakpoint IC in your board’s design. But to use such a breakpoint IC, all data, addresses, and control buses have to be connected and operational.

A µP-design example

As an example, the Tektronix TAS 400 series of analog oscilloscopes uses a µP with background-debug mode. These oscilloscopes’ CPU boards are generic enough to be applicable to almost any basic microcontroller design; Fig 3 shows that TAS 400’s CPU board is a 4-block design.

This board contains a µP, some memory, a dual asynchronous receiver/transmitter (DUART), and a custom readout IC. The RAM and flash EEPROMs have 256-kbyte capacity (you could easily increase capacity to 512 kbytes). The DUART performs timing and communication; the custom-readout IC serves as a character display for diagnostic purposes.

For this design, Motorola’s MC68331 µP with background-debug mode works well. In this application, the µP has the common support circuitry—such as a reset circuit, input pull-ups, and a system clock—of most µP designs. This µP requires all the typical communications signals along with seven additional signals for the background-debug mode: DS, BERR, BKPT/DSCLK, FREEZE, RESET, IFETCH/DSI, and IPIPE/DSO.

Bring up a new board

When first bringing up a system, reading or writing memory is sometimes impossible. A variety of potential problems can cause this fundamental failure—sometimes several occur simultaneously. Problems can stem from a simple wiring or design error or possibly from a short between connections. But the source of the problem can be more complicated, such as a bad I/O port or even the software of the debug monitor.

A first pass at debugging involves checking the voltages on all the ICs, the clock lines, the reset signal, and the other easily viewed signals. If these checks fail to reveal the problem, some method of generating bus transactions to view the address, data, and control lines in operation is necessary (Fig 4).

In the past, engineers added ROM sockets to the board for debugging and then burned small program loops into the ROMs. ROM-burn iteration and output inspection located the problem.

A µP with background-debug mode provides a more efficient and direct approach to troubleshooting prototype failures. By simply connecting the background-mode port and starting its associated PC software, an engineer can use a PC to isolate each IC on the board systematically. In background-debug mode, the µP queries individual ICs to test the quality of the communications link between the µP and the IC. This systematic approach allows verifying that the board’s hardware works without having to invoke its own software.

Once you check the µP and peripheral ICs, you can use the background-debug mode to verify that the software did indeed correctly configure the µP’s internal registers. Background-debug mode significantly simplifies bringing up a new µP board by dividing the complex problem of initial board failures into a series of small problems that you can solve easily.

Finding faulty components

An engineer can also rely on background-debug mode to locate µP-board power-up problems quickly. Often, a µP board doesn’t boot up when critical components fail.

To troubleshoot this problem, engineers typically have used an oscilloscope and the diagnostics that reside in ROMs on the µP board. But to execute these diagnostics, most µP systems require the µP, ROM, RAM, and data and address buses to be fully functional and error free. Hardware problems that shut down these basic operations force you to rely on trial and error to locate faulty hardware components, replacing parts until the system works.

To overcome this debugging limitation when the core system is not fully operational, you can easily inspect the µP’s internal registers and immediate peripherals. Using this approach, you can independently verify each component’s register contents and response to µP commands.

Programming flash EEPROMs

When designing µP-based, portable products, you must pay particular attention to parts count and cost. Although flash EEPROMs are extremely advantageous for these types of designs, they typically require a special boot ROM that contains download/erase code. But if the design includes a µP with background-debug mode, the download/erase code can reside on a PC. And you can eliminate the boot ROM.

To program the flash EEPROMs, you simply connect to the background port and download the EEPROM-burning code into the board’s system RAM. After starting the EEPROM-burning code’s execution via the background-debug-mode port, the code queries the PC for the firmware file. The burn code copies bytes of the firmware from the PC into a buffer in the system RAM. The burn code then uses an application-specific flash-burn algorithm to write from the buffer

into the flash EEPROM. The burn code fills the buffer and repeatedly burns the code until it has written all of the firmware file.

Inspect error logs

Typically, engineers do not include a communications port in a finished design because the port adds complexity and cost. But when your customers return defective products to your factory, you must analyze these products to understand the failure—and eliminate it in future products. To perform this analysis, you may need to access the the device’s internal operations.

If the design does not include a conventional communications port in the finished product, use background-debug mode as a port for error-log inspection. Often, µP-based systems contain diagnostic routines, which perform periodic self-evaluations, storing the results in nonvolatile memory. The results of these evaluations are often useful in failure analyses. Instead of having to use an ICE or install a communications port into each returned product, you can access and display the error log using background-debug mode.