Page 213 - Embedded Microprocessor Systems Real World Design

can get some of the features of an emulator without additional hardware even if
your application is running out of ROM.
Motorola also supports onchip debugging on many of its processors, including
the 68wColdfire family and the 68HCxx microcontrollers. Some Motorola proces-
sors use a technique called background debugging mode (BDM). BDM uses a connec-
tion to an external controller (such as a PC) to set breakpoints and examine trace
information. One advantage of the Motorola scheme is that the processor can con-
tinue running while memory and registers are examined. This is a useful feature
when the system is controlling motors or other devices that can cause damage if
the processor stops.
As I mentioned in Chapter 4, small microcontrollers often present a special
challenge. In these devices, the processor, RAM, and program memory are self-
contained, and all the pins are used for 1/0 functions. Consequently, there is no
way to see what addresses are being executed and what RAM locations are being
accessed. Sometimes you can build a special version of the controller that executes
from external memory. However, if your design uses all the controller’s 1/0 ports,
that is not an option. Many microcontrollers do not even support external memory.
Accessing 64K of external memory requires at least 19 data, address, and control
pins, assuming data is multiplexed with addresses. Microcontrollers such as the
Atmel AT9OS2313 and many of the Microchip PIC devices come in 18-, 20-, or
28-pin packages and simply lack enough pins to attach external memory. In a small
microcontroller design using one of these parts, you have five disadvantages:
You cannot use external RAM.
You cannot debug out of RAM (you must reprogram parts every time there is a
change).
You cannot set internal breakpoints (code is in PROM or flash memory).
Often, not enough code space is left for a debugger, even if one were available.
There is no way to see what internal addresses are being executed.

In a case like this, you are limited to using an emulator or adding debug techniques
like those described in Chapter 6. Fortunately, the code for most of these designs
is limited in complexity, if only because of limited code space, so debugging is less
of a problem than for more complex processors.

Functional Test Plan

Once the software and hardware are thought to be working, a test should be per-
formed to verify everything. A minimum test plan should describe every function
to be tested. A minimal test plan for the pool timer might look like this:

194 Embedded Microprocessor Systems