Professional Documents
Culture Documents
Chp10 SwConstr
Chp10 SwConstr
0 DEBUGGING TECHNIQUES
Introduction
Rule of Thumb: Write good, bug-free code from start if you could
Testing/Debugging embedded software is more difficult than application
software
Post-shipment application problems are more tolerable than embedded (real-
time or life-critical) software
10.0 DEBUGGING TECHNIQUES
Some reasons why you can’t test (much, if any) on target machine:
Basic Techniques
Fig 10.1 –
Basic Techniques
Fig 10.2 –
Radio.c -- hardware independent code
Radiohw.c – hardware dependent code (only interface to hw: inp() and outp()
supporting vTurnOnTransmitter() and vTurnOffTransmitter() functions
Inp() and outp() must have real hardware code to read/write byte data correctly -
makes testing harder!!
Fig 10.3 –
Replace radiohw.c with scaffold, eliminating the need for inp() and outp() – both
are simulated in software – a program stub!!
Figure 10.2 A Poor Plan for Testing
/* File: radio.c */
void vRadioTask (void)
{
.
.
.
!! Complicated code to determine if turning on the radio now
!! is within FCC regulations.
.
.
.
!! More complicated code to decide if turning on the radio now
!! makes sense in our protocol.
If (!! Time to send something on the radio)
{
vTurnOnTransmitter (FREQ_NORMAL);
!! Send data out
vTurnOffRadio ();
}
}
-----------------------------------------------
(continued)
Figure 10.2 (continued)
/* File: radiohw.c */
void vTurnOnTransmitter (int iFrequencyValue)
{
BYTE byPower; /* Byte read from device controlling power. */
int i;
/* Turn on main power for the radio. */
disable_interrupts ();
byPower = inp (PWR_CONTROL_ADDR);
byPower |= PWR_CONTROL_RADIO_MAIN;
outp (PWR_CONTROL_ADDR, byPower);
enable_interrupts ();
/* Shift the frequency value out to hardware. */
for (i = 0; i < 16; ++i)
{
/* Send out the lowest bit of iFrequencyValue */
if (iFrequencyValue & 0x0001)
{
/* The data is a binary 1 */
/* Put a '1' on the data line; pulse the clock line. */
outp (FRQ_CONROL, DATA_1 & CLOCK_LOW)
outp (FRQ_CONROL, DATA_1 & CLOCK_HIGH);
}
(continued)
Figure 10.2 (continued)
else
{
/* The data is a binary 0 */
/* put a '0' on the data line; pulse the clock line. */
outp (FRQ_CONROL, DATA_0 & CLOCK_LOW)
outp (FRQ_CONROL, DATA_0 & CLOCK_HIGH);
}
/* Shift iFrequencyValue to get the next lowest bit. */
iFrequencyValue >>= 1;
}
/* Turn on the receiver. */
byPower = inp (PWR_CONTROL_ADDR);
byPower |= PWR_CONTROL_RADIO_RECEIVER;
outp (PWR_CONTROL_ADDR, byPower);
enable_interrupts ();
}
void vTurnOffRadio (void)
{
BYTE byPower; /* Byte read from device controlling power. */
/* Turn off main power for the radio. */
disable_interrupts ();
byPower = inp (PWR_CONTROL_ADDR);
byPower &= ~PWR_CONTROL_RADIO_MAIN;
outp (PWR_CONTROL_ADDR, byPower);
enable_interrupts ();
}
------------------------------------------- (continued)
Figure 10.2 (continued)
/* File: test.c */
void outp (int Address, BYTE byData)
{
#ifdef LET_USER_SIMULATE_HARDWARE
PRINTF ("program wrote %02x to %04x.", byData, iAddress);
#endif
#ifdef SIMULATE_HARDWARE
!! Remember that software wrote byData to iAddress
!! Update state of simulated hardware.
#endif
}
BYTE inp (int iAddress)
{
int iData;
#ifdef LET_USER_SIMULATE_HARDWARE
PRINTF ("program wrote %02x to %04x. Enter value.",
iAddress);
scanf ("%x", &iData);
#endif
#ifdef SIMULATE_HARDWARE
!! Figure out what the real hardware would return
#endif
return ((BYTE) iData);
}
Figure 10.3 Better Plan for Testing
/* File: radio.c */
void vRadioTask (void)
{
.
.
.
!! Complicated code to determine if turning on the radio now
!! is within FCC regulations.
.
.
.
!! More complicated code to decide if turning on the radio now
!! makes sense in our protocol.
If (!! Time to send something on the radio)
{
vTurnOnTransmitter (FREQ_NORMAL);
!! Send data out
vTurnOffRadio ();
}
}
-----------------------------------------------
(continued)
Figure 10.3 (continued)
/* File: test.c */
static BOOL fRadionOn;
static int iRadioFrequencyValue;
void vTurnOnTransmitter (int iFrequencyValue)
{
/* Record the state of the radio. */
fRadionOn = TRUE;
iRadioFrequencyValue = iFrequencyValue;
/* Tell the user */
printf ("Radio turned on with frequency %04x", iFrequencyValue);
}
void vTurnOffRadio (void)
{
/* Record the state of the radio. */
fRadioOn = FALSE;
/* Tell the user */
printf ("Radio now off");
}
10.0 DEBUGGING TECHNIQUES
2) To test, structure the routine such that the hardware-dependent component (A)
calls the hardware-independent part (B).
3) Write component B in C-language, so that the test scaffold can call it
Making the scaffold automatically control sequence of events – e.g., calling the printer
interrupt many times but in a controlled order to avoid swamping
Making the scaffold automatically queue up requests-to-send output lines, by
automatically controlling the button interrupt routine, which will cause successive
pressing of a button to let the next output line be received from the hardware (the
printer interrupt routine). In this way, the hardware-independent software is
controlled by the scaffold, where the button interrupts serve as a switch
The scaffold may contain multiple instances of the software-independent code, and the
scaffold serves as a controller of the communication between the instances – where
each instance is called by the scaffold when the hardware interrupt occurs (e.g., the
scanner or the cash register). In this way, the scaffold simulates the hardware
(scanner or register) and provides communication services to the software-
independent code instances it calls. – See Fig 10.7
10.0 DEBUGGING TECHNIQUES
Simulator – must understand the linker/locator Map format, parse and interpret it
Simulator – takes the Map as input, reads the instructions from simulated ROM,
reads/writes from/to simulated registers
Provide a user interface to simulator for I/O, debugging (using, e.g., a macro
language)
10.0 DEBUGGING TECHNIQUES
Capabilities of Simulators:
Collect statistics on # instructions executed, bus cycles for estimating actual times
Easier to test assembly code (for startup software and interrupt routines) in simulator
Easier to test for portability since simulator takes same Map as the target
Other parts, e.g., timers and built-in peripherals, can be tested in the corresponding
simulated versions in the simulated microprocessor architecture
(See Fig 10.10, Fig 10.11, Fig 10.12, Fig 10.13, Fig 10.14)
10.0 DEBUGGING TECHNIQUES
Logic Analyzer
Like storage scopes that (first) capture many signals and displays them simultaneously
It knows only of VCC and ground voltage levels (displays are like timing diagrams) –
Real scopes display exact voltage (like analog)
Can be used to trigger on-symptom and track back in stored signal to isolate problem
Many signals can be triggered at their low and/or high points and for how long in that
state
Used in Timing or State Mode
10.0 DEBUGGING TECHNIQUES
Find out if an event occurred – did cordless scanner turn on the radio?
Measure how long it took software to respond to an interrupt (e.g., between a button
interrupt signal and activation signal of a responding device – to turn off an bell)
Is the software putting out the right pattern of signals to control a hardware device –
looking back in the captured signal for elapsed time
(See Fig 10.17 – a typical Logic Analyzer with on-screen button, mouse, keyboard,
network adaptor, disk storage for storing configurations/settings, ribbon cables)
10.0 DEBUGGING TECHNIQUES
ICE v. LA
LA’s have better trace and filtering mechanism, and easier to detail and find problems
LA’s run in timing mode
LA’s work with any microprocessor – ICE is microprocessor-specific
LA’s support many but select signals to attach, ICE requires connecting ALL signals
ICE is more invasive
10.0 DEBUGGING TECHNIQUES
Software-Only Monitors
Monitors allow running an embedded system in the target environment, while
providing debugging interfaces on both the host and target environments
A small portion of the Monitor resides in the target ROM (debugging kernel or monitor):
The codes receives programs from serial port, network, copies into target’s RAM, and run it
with full debugging capabilities to test/debug the programs