|
3
Gordon Drive, P.O.Box 1347 Rockland, Maine 04841 U.S.A.
|
|
© 2004 Avocet Systems, Inc.
|
Call
Us Today at 207-596-7766 ("Picton Press")
|
|
Avocet Systems, Inc. : The Complete Solution for Embedded Systems
Development Tools
|
|
|
Hints
Proactive Debugging
Abstract
Most of the time we debug by finding a symptom and then endlessly chasing that
one problem. Why not set up traps for likely troubles, and let the hardware
find these problems?
Doesn't it seem strange that we debug programs reactively? Instead of developing
a debug plan and strategy, most developers turn the system on, look for a something
that works incorrectly, and start chasing that bug. Then we iterate, sometimes
seemingly forever. Version 10.5 of SLD (due out in Spring, 2001) will have two
buttons: FIND_BUG and FIX_BUG. Till then, use every conceivable resource to
optimize your efforts! Anticipate problems! Set up conditions to test for and
catch the problems before they become obscure and hard to find. For example,
an array-out-of-bounds condition may not become apparent until after the code
is written over - at which point it can be very, very difficult to find the
source of the bug.
This example suggests a proactive debugging strategy - make sure your compiler
has all runtime error checking enabled. Since most embedded systems don't support
a device that displays error messages either write an error handler that substitutes
for the normal runtime handler, or simply set a breakpoint on the handler address.
Always set this breakpoint before each debugging session using a batch file
(in SLD, these are .CMD files). Then, if the problem shows up unexpectedly -
they always show up unexpectedly - the emulator will immediately stop the code
and wave a warning flag. As this example illustrates, breakpoints are a prime
debugging resource for both reactive and proactive debugging, as long as your
emulator supports lots of them... enough that you can afford to permanently
leave some seeded on possibly critical error handlers and the like. One of the
reasons Softaid's UEM has 131,072 hardware breakpoints is to support this sort
of debugging environment.
Memory Monitor
Another resource is the UEM's Memory Access Monitor. In effect, the Monitor
is a bus watcher that compares every memory transaction against rules you supply.
Thinking proactively, before starting on a project you'd set up a batch file
that profiles the memory space of your system, with access rules for each area.
Common sense defines the rules. Most embedded systems run code from ROM. ROM
is inherently read-only, so a reasonable rule would be to error if any write
occurs to the code area. (One of Softaid's biggest source of support calls comes
from folks whose code runs fine from ROM, but not at all from Overlay RAM. The
culprit is always a previously-undetected bug that causes writes to code space.)
Unless your system supports self modifying code, RAM should be flagged as "no
execution allowed", so the Monitor can capture an errant jump to RAM. Remember
that something as simple as an incorrect interrupt vector can cause a jump to
RAM, which is terribly difficult to track down when thinking reactively. Finally,
any section of memory that is not used should be tagged as "no accesses allowed".
The Monitor will alert you to code breaking this rule, which could be due to
interrupt vector problems or a number of other conditions. The Monitor has no
impact on the execution of your code. It injects no wait states or other slow
downs, but just runs quietly in the background, checking each and every memory
access against your rules. A rule violation will stop the code immediately,
so you can discover what caused the problem. A particularly effective debugging
technique is to arm the real time trace in concert with the Monitor. Then, a
Monitor breakpoint will stop trace collection. You can look in the trace buffer,
looking back in time, to see what events led up to the rule violation. The key
to most proactive debugging strategies is to anticipate problems before they
occur, then to design a method to catch the bug. Equally important, you must
automate the process so your traps are enabled all of the time.
Batch Files
Generally you set the Monitor up once only once per project. We recommend that
you define your code and data spaces, and then determine where there will be
neither code nor data. Create a batch file to set the Monitor up every time
you load SLD. You can set up the Memory Access Monitor from the Command Journal
or a .CMD file using the MON command. It takes the following form: MON start,
end, rule
Where start and end define the address range for the rule, and rule comes from
the set: AA - allow any access NA - any access is illegal WP - writes are illegal
NF - fetches are illegal
Suppose you have ROM from 0f0000 to 0fffff and RAM from 0 to 3ffff. Presumably,
the memory in between ROM and RAM is unused and should never be accessed. Set
the monitor up as follows: For no fetches in RAM: MON 0,3ffff,NF
For no writes to ROM: MON 0f0000,0fffff,WP
For no accesses except to ROM and RAM: MON 40000,0effff, NA
Copyright 1994, Softaid, Inc.
|
|
|
Products