Writing Code for Debug

8/10/2019 Writing Code for Debug

1/69

Writing Code For Debug


2/69

What is Debugging?

Debugging is the art of removing bugsfrom software.

Debuggingis identifying the problem

and providing the solution to thesoftware program.


3/69

Debugging

An error in a computer program is called a bug.

The process of finding & fixing these bugs is called

debugging.

There are several tools to help us debug programs.

When an error occurs, we dont know which line

causes the error.

To find the error, we can either:

Read the code, think about the logic, and hopefully

find the error

Failing that, we can print relevant variables at

different points of the code, and see where the

variables values deviate from what you expect


4/69

Aspects of debugging C code

Noticing

Notice the bug by running test case.

Localising

Identify the area of the bug

Understanding

Understand fullyis programming mistake or

algorithm is in correct.

Repairing bugs

Modifying the code with fix. Check for any side

effects.


5/69

Types of bugs

Semantic bugs

Using uninitialized variables

Array boundaries

Using out of range value

Pointer bugs Trying to use memory that has not been allocated

yet.

Trying to access memory that has been de-

allocated already.


6/69

Common Mistakes

Programming without thinking

Writing code in an unstructured

manner

Works for some cases.

Too many Bugs

Hard to understand

Hard to debug

Hard to fix bugs


7/69

Thinking about Programming

First design the program by thinkingabout the numerous ways the

problem's solution may be found.

How does one design a programbefore coding?

Different techniques (top-down

design) Top-down design divides the program

into sub-tasks.


8/69

Thinking about Programming

Each sub-task is a smaller problemthat must be solved.

Problems are solved by using an

algorithm. Functions (and data) in theprogram implement the algorithm.

Trace with different inputs to check

algorithm manually. When confident that algorithm works

then start implementing the code.


9/69

Structured Programming

Writing structured programs helpsgreatly in debugging the code.

Some of the features of a structured

program: Lots of well-defined functions!

Using structured loop constructs (i.e., while and

for) instead of goto.

Using variables that have one purpose and

meaningful names.

Using structured data types to represent complex

data.


10/69

Structured Programming

When a program is structured, it isdivided into sub-units that may be

tested and debugged separately.

Storing the sub-units of a program intoseparate source files can make it

easier to debug them separately.

Sub-units can often be reused in otherprograms.


11/69

Designed & Structured Code

Program with NO or very few bugs

Easy to understand the program by

any one.

Easy to debug the code.

Easy to fix the bug.


12/69

Other Important things.


13/69

Following Coding

Conventions Set of rules for naming the file names

Ex: module_init.c, module_init.h

Function and variable naming

Ex: module_open(), module_close()

Ex: bool g_module_init_done;


14/69

Documentation

Documentation helps a lot tounderstand and debug the code.

Write comments About the file

Function Description

Any complex mathematical operation

Magic values

Complex conditions


15/69

Adding Debug Prints

Add prints to log the execution flow.

Enable prints for debug only.

Add prints for all error conditions. And

enable all the time.


16/69

Memcpy()/* memcpy-- copy a non overlapping memoryblock */

void *memcpy(void *pvTo,void *pvFrom, size_t size)

{

byte *pbTo = (byte *) pvTo;

byte *pbFrom = (byte *) pvFrom;

if ( pvTo == NULL || pvFrom == NULL )

{

fprintf(stderr, Bad args in memcpy\n);

halt();

}

while ( size-- > 0 )

{

*pbTo++ = *pbFrom++;

}

return( pvTo );

}


17/69

Memcpy() with DEBUG/* memcpy-- copy a non overlapping memoryblock */

void *memcpy(void *pvTo,void *pvFrom, size_t size)

{



#ifdef DEBUG

if ( pvTo == NULL || pvFrom == NULL )

{

fprintf(stderr, Bad args in memcpy\n);

halt();

}

#endif


{

*pbTo++ = *pbFrom++;

}

return( pvTo );

}


18/69

Add asserts

The assert is used (with a boolean-expression parameter) to check

assumptions

If the expression is TRUE nothinghappens, if FALSE, a message is

printed and the program can be

stopped.


19/69

Memcpy() with Assert

/* memcpy-- copy a non overlapping memoryblock */void *memcpy(void *pvTo,void *pvFrom, size_t size)

{



assert( !((pvTo == NULL) || (pvFrom == NULL)) );


{

*pbTo++ = *pbFrom++;}

return( pvTo );

}


20/69

Debugger functions

No matter which debugger or IDE youre using, adebugger always has the following basic

functionalities:

Start: Start executing the program in debug mode.

Set/remove breakpoint: Set/remove a breakpoint at aline of code. When the program runs to a line of code

with a breakpoint set, it pauses and waits for user

command

Step: Run one line of code Show variable: Display the value of a variable at this

time

Continue: Continue running the program (until the

next breakpoint is reached)

Move up the stack: Examine the variables at other


21/69

Debugging Techniques

Rule of Thumb: Write good, bug-freecode from beggining

Testing/Debugging embedded

software is more difficult thanapplication software

Post-shipment application problems

are more tolerable than embedded(real-time or life-critical) software


22/69

Some reasons why you cant test on targetmachine:

Test early (target may not ready or

completely stable)

Exercise all code, including exceptions (real

situations may be difficult to exercise)

Develop reusable, repeatable test (difficult to

do in target environment, and likelihood ofhitting the same bug is low)

Store test results (target may not even have

disk drive to store results)

Testing on Host Machine


23/69


Target system on the left: (hardware-indep code, hardware-dep code, hw)

Test system (on host) on the right:

(hardware-indep codesame,scaffoldrest)

Scaffold provides (in software) all

functionalities and calls to hardwareas in the hardware-dep and hardware

components of the target system

more like a simulator for them!


24/69


25/69


Radio.c -- hardware independent code

Radiohw.chardware 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!!

Replace radiohw.c with scaffold, eliminating the need

for inp() and outp()both are simulated in softwarea

program stub!!


26/69

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)


27/69

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)


28/69

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 |= PWR_CONTROL_RADIO_RECEIVER;



}

void vTurnOffRadio (void)

{

BYTE byPower; /* Byte read from device controlling power. */

/* Turn off main power for the radio. */

disable_interrupts ();


byPower &= ~PWR_CONTROL_RADIO_MAIN;



}

------------------------------------------- (continued)


29/69


/* 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);

}


30/69

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)


31/69


/* File: test.c */

static BOOL fRadionOn;static int iRadioFrequencyValue;

oid vTurnOnTransmitter (int iFrequencyValue)

{

/* Record the state of the radio. */

fRadionOn = TRUE;

iRadioFrequencyValue = iFrequencyValue;

/* Tell the user */

printf ("Radio turned on with frequency %04x", iFrequencyValue);

}

oid vTurnOffRadio (void)

{/* Record the state of the radio. */

fRadioOn = FALSE;

/* Tell the user */

printf ("Radio now off");

}


32/69

Testing on Host Machine Calling Interrupt Routines

Embedded systems are interrupt-driven, so to test based on interrupts

1) Divide interrupt routines into two components

A) a component that deals with the hardware

B) a component of the routine which deals with the rest of the system

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

Hw component (A) is vHandleRxHardware(), which reads characters from the hw

Sw component (B) is vHandleByte, called by A to buffer characters, among others

The test scaffold, vTestMain(), then calls vHandleByte(), to test if the system works

[where vTestMain() pretends to be the hardware sending the chars to vHandleByte()]


33/69

Figure 10.4 Dividing Interrupt Routines into Two Parts

/* File: serial.c */

#define CR 0x0d

#define SIZEOF_CMD_BUFFER 200BYTE a_byCommandBuffer[SIZEOF_CMD_BUFFER];

/* Queue to send message to command-handling task. */extern unsigned long qidCommands;

void interrupt vHandleRxHardware (void){

BYTE byChar; /* The character we received */int iHwError; /* Hardware error, if any */

iHwError = !! Get status from hardware;

if (iHwError == CHARACTER_RXD_OK){

/* We received a character; deal with it. */byChar = !! Read byte from hardware;

vHandleRxByte (byChar);}else

!! Deal with hardware error!! Reset the hardware as necessary.!! Reset interrupt controller as necessary.

} (continued)


34/69


void vHandleRxByte (BYTE byReceived)

{

static BYTE *p_byCommandBufferTail = a_ byCommandBuffer;extern BYTE *p_byCommandBufferHead;

unsigned long a_ulMessage[4]; /* Message buffer. */

/* Advance the tail pointer and wrap if necessary */

++ p_byCommandBufferTail;

if (p_byCommandBufferTail == &a_ byCommandBuffer

[SIZEOF_CMD_BUFFER])

p_byCommandBufferTail = a_ byCommandBuffer;

/* If the buffer is not full . . . . */

if (p_byCommandBufferTail != p_byCommandBufferHead)

{

/* Store the character in the buffer. */

*p_byCommandBufferTail = byReceived;

/* If we got a carriage return, wake up the command-handling task. */

if (*p_byCommandBufferTail == CR)

{/* Build the message . . . */

a_ulMessage[0] = MSG_COMMAND_ARRIVED;

a_ulMessage[1] = 0L;



(continued)


35/69


/* . . . and send it. */

q_send (qidCommands, a_ulMessage);

}

}

else

{

/* Discard the character; move the pointer back. */

if (p_byCommandBufferTail == a_ byCommandBuffer)

p_byCommandBufferTail ==

&a_ byCommandBuffer[SIZEOF_CMD_BUFFER];

-- p_byCommandBufferTail;

}

}

--------------------------------------------

/* File: test.c */

oid vTestMain (void)

{

BYTE a_byTestCommand[] = "THUMBS UP\x0dSIMON SAYS THUMBS UP\x0d";

BYTE *p_by;../* Send each of the characters in a_byTestCommand */

p_by = a_byTestCommand;

while (*p_by)

{/* Send a single character as though received by the interrupt */

vHandleRxByte (*p_by);

/* Go to the next character */

++p_by;

}..

}


36/69


Calling the Timer Interrupt Routine

Design the test scaffold routine to

directly call the timer interrupt routine,

rather than other part of the hostenvironment, to avoid interruptions in

the scaffolds timing of events.

This way, the scaffold has control oversequences of events in the test which

must occur within intervals of timer

interrupts.


37/69


Objections, Limitations, and Shortcomings 1) Hard to test parts which are truly hardware

dependent, until the target system is operational.Yet, good to test most sw-independent parts onhost.

2) Time and effort in writing scaffoldeven ifhuge, it is worthwhile

3) The hard to justify limitationscant tell inscaffold until the actual test Writing to the wrong hardware addresssoftware/hardware

interactions Realistic interrupt latency due to differences in processor

speeds (host v. target)

Real interrupts that cause shared-data problems, where realenable/disable is the key

Differences in network addressing, size of data types, data

packing schemesportability issues


38/69


39/69

Instruction Set Simulators

Using software to simulate: The target microprocessor instruction set

The target memory (types - RAM)

The target microprocessor architecture

(interconnections and components)

Simulatormust understand the linker/locator Map

format, parse and interpret it

Simulatortakes the Map as input, reads theinstructions 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)


40/69

Instruction Set Simulators

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 thetarget

Other parts, e.g., timers and built-in peripherals, can be tested in the

corresponding simulated versions in the simulated microprocessor

architecture

What simulators cant help:

Simulating and testing ASICs, sensors, actuators, specialized radios

(perhaps, in future systems!!)

Lacking I/O interfaces in simulator to support testing techniques

discussed (unless additional provision is made for I/O to support the

scaffold; and scripts to format and reformat files between the


41/69

The assert Macro

Assert works well in finding bugs early, when testing inthe host environment

On failure, assert causes a return to the host operatingsystems (cant do on target, and cant print suchmessage on targetmay not have the display unit)

Assert macro that runs on the target are useful forspotting problems: 1) disabling interrupts and spin in infinite loopeffectively stopping

the system

2) turn on some pattern of LEDs or blinking device

3) write special code memory for logic analyzer to read

4) write location of the instruction that cause problem to specificmemory for logic analyzer to read (the Map can help isolate whichsource code is the culprit!)

5) execute an illegal op or other to stop the systeme.g., using in-circuit emulators


42/69

U i T l H d


43/69

Using Tools Hardware-

focused Lab tools help reveal hard-to-find, very infrequently

occurring bugs

Types useful to software engineers:

Multi-meter(measure voltage/current/connectivity)

Oscilloscopes (scopes) test events that repeatperiodicallymonitoring one or two signals (graph of

time v. voltage), triggering mechanism to indicate start

of monitoring,

adjust vertical to know ground-signal, used as voltmeter

(flat graph at some vertical relative to ground signal),test if a device/part is workingis graph flat? Is the

digital signal coming throughexpecting a quick

rising/falling edge (from 0VCC or VCC0)if not,

scope will show slow rising/fallingindicating loading,

bus fight, or other hardware problem.


44/69


45/69


46/69


47/69

U i T l H d


48/69

Using Tools Hardware-

focused 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 scopesdisplay 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

L i A l i Ti i


49/69

Logic Analyzers in Timing

Mode Find out if an event occurredBy

external device

Measure how long it took software to

respond to an interrupt (e.g., between abutton interrupt signal and activation

signal of a responding device)

Is the software putting out the rightpattern of signals to control a hardware

devicelooking back in the captured

signal for elapsed time


50/69


51/69

L i A l i St t


52/69

Logic Analyzers in State

Mode

Captures signals only on clock-event occurring from the attachedhardware

Typical use: instructions read/fetched by microprocessor, data read

from or written to ROM, RAM, or I/O devices

To do so, connect LA to address and data signals and RE/ signal on

the ROM (or RAM)

If triggering is on rising edge of RE/ pin, address and data signals

will be captured

Output of LA, called trace, is stored for later analysis

LA can be triggered on unusual event occurrences, then capture

signals therefromespecially for debugging purposes (e.g., writing

data to wrong address, tracking a rarely occurring bug, filtering

signals for select devices or events)

LA cant capture all signals, e.g., on fetch from caches, registers, un-

accessed memory


53/69


54/69

In-Circuit Emulators (ICE)

Replaces target microprocessor in target circuitry Has all the capabilities of a software debugger

Maintains trace, similar to that of an LAs

Has overlay memory to emulate ROM and RAM for a specified

range of address within the ICE (rather than the systems main ROM

or RAM)facilitates debugging

ICE v. LA

LAs have better trace and filtering mechanism, and easier to detail and find

problems

LAs run in timing mode

LAs work with any microprocessor ICE is microprocessor-specific

LAs support many but select signals to attach, ICE requires connecting ALL

signals

ICE is more universal

H d P li iti th t M k


55/69

Hardware Peculiarities that Make

Debugging Difficult Inter-pin distances/intervals for attachingprobesgetting smaller

Providing sockets for debugginghardwaresimply increases product

size Use of RISC architectural designs makes

it difficult to track when read/write

happen in on-board (microprocessor)cachesdifferent from the external RAMor ROM

Increasingly necessary to know the lab

tool chain as it influences the design of


56/69

Software-Only Monitors

Monitors allow running an embedded system in the targetenvironment, 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, copiesinto targets RAM, and run it with full debugging capabilities to

test/debug the programs

Another portion of monitor resides on hostprovides debugging

capability and communicates with the debugging kernel over

serial port or network, without hardware modifications Compiled, linked (may be located into Map) code is downloaded

from the host (by the portion on the host) to the target RAM or

flash (received by the kernel)


57/69


58/69

Logging

Logging is the process of recordingevents, with an automated program.

To provide an audit trail that can be

used to understand the activity of thesystem and to diagnose problems.

To understanding the activities of

complex systems particularly in thecase of applications with little user

interaction (such as server

applications).


59/69

Examples

Physical systems which have loggingsubsystems include process control

systems (Telemetry).

Black box recorders in aircraft. Many operating systems and

multitudinous computer programs

include some form of loggingsubsystem.

Log messages are written to a log file /

memory.


60/69

Interpreting Logs

logs are esoteric or too verbose andtherefore hard to understand.

Logs are analyzed with special log

analysis software. Ex: USB data packets log

Ex: Network data packets log


61/69

Transaction Logs

Database systems maintains separatelog called transaction log.

This is used to recover the database

from crash. Maintain the data in consistent state.


62/69

Data Loggers

A data logger is an electronic devicethat records data over time.

Generally they are small, battery

powered, portable, and equipped witha microprocessor, internal memory for

data storage, and sensors.

Connected to PC to analyze the data.


63/69

Tracing

Tracing is a specialized use of loggingto record information about a

program's execution.

This information is typically used byprogrammers for debugging purposes.

Provides low level information of the

programs execution.


64/69

Software tracing

Provides Developers with informationuseful for debugging.

It is used both during the development

cycle and after the software isreleased.

Tracing messages should be kept in

the code, they can add to thereadability of the code.


65/69

Some Considerations

Performance of the system. Tracing data may include sensitive

information about the product's source

code. Security information like secretkey.

Disable tracing at compile time in

release software.


66/69

Diagnostics

A diagnostic program is a programwritten for the express purpose of

locating problems with the software,

hardware, or any combination thereofin a system, or a network of systems.

Preferably, diagnostic programs

provide solutions to the user to solveissues.


67/69

Examples

Diagnostics that are run on-demand when auser needs assistance, typically within the

primary operating system of the computer

(e.g. Linux, Windows)

"Off-line diagnostics" that are run outside theprimary operating system, typically to reduce

the masking influence of software on

hardware issues.

Background diagnostics that monitor the

system for failures and marginal events, and

provide statistical data for failure prediction,

and root cause analysis of actual failure


68/69

Types of Diagnostics

Manufacturing testing program with anemphasis on checking assembly-

related issues.

End-user targeted diagnostics, easy,non-technical and an emphasis on

solutions.

Service/warranty testing, focusing onidentifying a failed unit.

Hardware components have specific

features to assist a diagnostic


69/69

Questions?

Writing Code for Debug

Documents

Transcript of Writing Code for Debug