| |
|
June 4, 1998
Debugging embedded systems: using a serial condition monitor to
overcome limited diagnostic access
Stuart R Ball
If your µC-based design is short on pins, you can perform
diagnostics via only one pin by implementing a serial condition monitor.
If your µC-based design has only one pin free for diagnostic use, you can implement a
serial condition monitor to provide at least some diagnostic information over that pin.
Your implementation can monitor conditions in your software and report on those conditions
via serial bit transmissions, which go to an attached oscilloscope. Your software sends a
start bit to trigger the scope at an appropriate time, and then sends data one bit at a
time. By setting the data bits either on or off, your software provides displayable
information about its own status (Figure 1).
A serial condition monitor provides limited information, because it can send only a few
bits--typically less than a byte. If you display as many as eight bits on a scope screen,
it's difficult to determine from the display which bits are ones and which bits are zeros.
Also, a serial condition monitor can't generate a display as often as you might want,
because the scope would have difficulty triggering. Typically, you send serial condition
data each time your code goes around its background loop or every time it services a
regular timer interrupt.
Still, the information from a serial condition monitor can be helpful. For example, it
might include a bit to indicate when a motor is active, when one system is waiting for
another, or when a receive or transmit FIFO contains enough data. However, a serial
condition monitor technique isn't well suited to displaying events that come and go very
quickly, because the events are too hard to see on a scope. Listings
1 and 2 show routines for sending serial status
information for an 8031 and a PIC17C42, respectively. Other routines set and reset the
bits that indicate status.
Ideally, a software monitor program needs a serial port to operate, but you might
not always have a serial port available. The 8031, for example, has only one serial port,
and your design will probably need the port for its own use, thus excluding it from
diagnostic use. Also, if your design uses a µP that doesn't have an on-chip serial port,
you might not want to add a hardware UART just for debugging. However, if you have a spare
pin on the µC you're using, or if you have a spare register output bit on a multichip
processor design, you can implement a serial port in software.
An example of a software serial port, using a technique sometimes called bit banging,
appears in Listing 3. With this code, written for the
8031, or with similar code for another processor, you can implement a post-mortem dump of
memory after a failure. Your software can activate the routine after a hardware reset
(manually initiated when an error occurs) or via an unused interrupt.
Listing 3's code transmits 128 bytes of memory to a PC,
sending each byte of RS-232C serial data as a low-level start bit, followed by eight data
bits (LSB first), and then a high-level stop bit (assuming no parity). The code converts
each byte in memory to two hex digits, separating each pair of digits with a space. A
carriage return and line feed go after every 16 digits. The logic levels invert before
going to the RS-232C connector.
The code in Listing 3 uses one of the 8031's internal
timers, but you could instead use software loops for timing. Implementing software timing
loops is fairly straightforward on the 8031, but less so on more complex processors, where
independent bus interfaces and execution cores make timing less predictable. On more
complex processors, especially, a hardware timer is easier to use.
It's also possible to implement a serial receive routine in software, although it might
not be particularly useful. You can construct a complete monitor program around send and
receive serial routines, but it would be somewhat limited. The processor can't do anything
else while receiving or transmitting, and the interface is half duplex, so you can't
receive and transmit at the same time. On a very fast processor, you can implement a
full-duplex UART in software with a regular timer interrupt that operates at 4×, 8×, or
some other multiple of the baud rate. The fast interrupts really tie the processor up,
though.
Even so, a software serial routine is sometimes useful. Listing
4's routine, written for an 8031, functions as an interrupt service routine (ISR),
with serial data connected to the 8031 INT0 interrupt pin. With INT0 programmed to be
edge-sensitive, the ISR reads serial data when the leading edge of the start bit occurs.
Note that if other, higher priority interrupts occur, the interrupt latency for the
serial-receive code might be too long for reliable operation.
If you want a full serial interface for debugging, but you can't justify adding
hardware to every production board just in case it's needed, consider connecting processor
data-bus and control lines to a pin header. You can then build a single serial interface
daughterboard containing a UART and an RS-232C interface (Figure 2).
The serial interface board connects to the pin header, and you plug it in only when you
need to debug a problem.
If you have a spare interrupt available for your serial interface, you can leave a
ROM-based debugger resident in your program (but beware of license fees!) and activate it
when a character arrives via the serial interface. If you pull the interrupt to the
inactive state on the processor board, the software won't respond to an interrupt on that
line unless you have the serial board installed. Another means of testing for the serial
board's presence is with a bit on the processor board, also connected to the header
connector, that you can test with your software. You pull up the bit on the processor
board and ground it on the serial board. Regardless of how you test for the serial board's
presence, you don't want the software to execute your debugger code unless the board is
installed.
References
- Ball, Stuart R, "Debugging
embedded systems: using a trace buffer to see what went wrong," EDN, April
9, 1998, pg 161.
- Ball, Stuart R, "Debugging
embedded systems: using hardware tricks to trace program flow," EDN, April
23, 1998, pg 163.
Author's biography
Stuart Ball, PE, is an electrical engineer who has spent the last 16 years designing
digital, analog, and embedded-µP systems. He is the author of two books, Embedded
Microprocessor Systems, Real World Design
and Debugging Embedded Microprocessor Systems, both published by Newnes (Woburn, MA).
He is currently employed at Organon-Teknika (Oklahoma City, OK), a manufacturer of medical
instruments. |
