Strategies and Methods for Debugging15-1Embedded SystemsDebuggingThe best way of debugging is to avoid creating the bugs– Stop writing big programs, since complexity scales exponentially– Follow good coding practices: modular code, OOP, top-down decomposition, code walk-throughs, etcEmbedded systems allow limited visibility of system state, so develop as much of the system on a more friendly platform“It should be working, but it isn’t –it doesn’t make sense!” Embedded Systems 15-2“It should be working, but it isn’t –it doesn’t make sense!” really means “One of my assumptions is wrong. I need to find out which it is and why.”Debugging Concepts – Think and TestDetermine what works and what does not– As system grows more complex, faults become visible later in program, obscuring the sources of error– Your brain is an essential part of the debug process, regardless of tools–Assume everything you have written is broken until you prove Embedded Systems 15-3–Assume everything you have written is broken until you prove it works• Rely on as little of system as possible when debugging– Blame yourself first and the hardware last• Assume that the chip is doing what you tell it to doDebug Process (repeat until bug-free)Observe behavior to describe the bugGather other related information to flesh out description of bugCheck common problems, based on experienceGenerate hypothesis of possible cause of bug– May need to gather even more info with test toolsCreate experiment to test that hypothesisEmbedded Systems 15-4Create experiment to test that hypothesis– What will this experiment prove?Run the experimentDebugging Concepts – Observation and RepeatabilityA processor can execute many millions of instructions in one second, and humans can’t handle time on that scale– Set output bits to indicate when specific events occur, allowing scope to trigger on useful infoNeed to make inputs repeatable– Repeatability is fundamental for debugging• Code must have same control flow and data values Embedded Systems 15-5• Need to be sure changes in system behavior are a result of changes to source code rather than system inputs– Embedded systems read I/O devices• Must configure devices to behave the same each time– e.g. stimulus file in simulator• May need to write test functions that emulate input devicesDebugging Concepts - ToolsNeed two tools for embedded real-time systems– Debugger: examine functional behavior• How many times does the loop execute?• Does the program recognize the error condition and execute this branch of the conditional?• Examples: gdb, KD30Embedded Systems 15-6– Monitor: examine temporal behavior• When does the pulse occur?• How long does it take to respond to the interrupt?• Examples: oscilloscope, logic analyzerFunctional Debugging 1Supply inputs, run system, compare outputs against expected resultsCan add debugging instruments (modify your source code) to supplement/enhance debuggerSingle stepping or trace– Can step at source level or assembly level–Can step down into called functions or over them, or finish existing Embedded Systems 15-7–Can step down into called functions or over them, or finish existing onesBreakpoints– Can halt program execution at a given point in source code– Conditional breakpoints are aware of program state, reduce false triggersTrade-OffsSingle-stepping (SS) vs. Breakpoints (BP)– SS gives complete control and visibility into the program’s control flow, but may require many, many steps• Scales very badly as program increases– Fast execution up to BP, but you don’t know what code executed before itForward vs. Backward Search– Forward: Find point in program where state is good, then work forward until bad data/behavior is found• Need to be methodical and keep track of location–Backward: Find point in program where state is bad, then rerun to earlier Embedded Systems 15-8–Backward: Find point in program where state is bad, then rerun to earlier points• The original bug’s nature may be masked by code which follows it, complicating debugging• Garbage In, Garbage Out: just because this function’s output is bad doesn’t mean the function has a bug!• One bug may trigger other bugs, so you may end up tracking multiple bugs to fix oneForward search is much more efficientHow Do We Know If The Program State Is Good?Motivation– The sooner we find a bug, the sooner we can fix it– The sooner we know a bug has executed, the sooner we can find it.Helps to have functions which check the program state to see if it is good or bad– Simple for basic data typesEmbedded Systems 15-9– More sophisticated data structures should have a check function– Can conditionally compile the check code, leaving it out of production (release) code for speed– Might still want to leave it in to get more detailed bug reports laterSerial I/O Queues#define Q_SIZE (32)#define Q_SIZE (32)#define Q_SIZE (32)#define Q_SIZE (32)typedef struct {typedef struct {typedef struct {typedef struct {unsigned char Data[Q_SIZE];unsigned char Data[Q_SIZE];unsigned char Data[Q_SIZE];unsigned char Data[Q_SIZE];unsigned int Head; // points to oldest data elementunsigned int Head; // points to oldest data elementunsigned int Head; // points to oldest data elementunsigned int Head; // points to oldest data elementunsigned int Tail; // points to next free space unsigned int Tail; // points to next free space unsigned int Tail; // points to next free space unsigned int Tail; // points to next free space unsigned int Size; // quantity of elements in queueunsigned int Size; // quantity of elements in queueunsigned int Size; // quantity of elements in queueunsigned int Size; // quantity of elements in queue} Q_T;} Q_T;} Q_T;} Q_T;Embedded Systems 15-10Q_T tx_q, rx_q;Q_T tx_q, rx_q;Q_T tx_q, rx_q;Q_T tx_q, rx_q;What should always be true for this type of data structure?– Size <= Q_SIZE– (Head – Tail + Q_SIZE) % Q_SIZE == SizeRound-Robin Scheduler Task Tabletypedef struct {typedef struct {typedef struct {typedef struct {int initialTimerValue; int initialTimerValue; int initialTimerValue; int initialTimerValue; // “frequency” of task// “frequency” of task// “frequency” of task// “frequency” of taskint timer;int timer;int timer;int timer; // time to next “run”// time to next “run”// time to next “run”// time to next “run”int run;int run;int run;int run; // binary
View Full Document
Unlocking...