An Embedded Software Primer David E Simon 5312006

An Embedded Software Primer David E. Simon 5/31/2006

Chapter 10: Debugging Techniques 1. 2. 3. 4. Testing on Your Host Machine Instruction Set Simulators The assert Macro Using Laboratory Tools 5/31/2006 2

Testing on Your Host Machine Testing processes typically have the following goals: n Find bugs early in the development process Saves time and money ¡ Gives an early idea of how much effort will be needed BUT: target hardware normally not available so early or still being tested ¡ n Exercise all code Test for all exceptional cases or errors BUT: some errors or exceptions very difficult to simulate in lab. e. g. a printer might have to deal with a particular error where user presses a button just as paper jams. However it may be difficult to test this by jamming the paper and pressing the button within a millisecond ¡ n Develop reusable, repeatable tests Frustrating to reinvent same tests for version 2 as were used in version 1 BUT: often difficult to create repeatable tests for target e. g. suppose a bug arises in a cordless bar-code scanner when user pulls trigger while it is acknowledging previous scan. It might not be possible to re-create and fix the bug again ¡ n Leave “audit trail” of test results Noticing the Telegraph “works” in network environment not as valuable as knowing and storing the exact data it sends out in response to received data BUT: most embedded systems don’t have disk drives or storage mediums to store results ¡ 5/31/2006 3

Testing on Your Host Machine (contd. ) n n Conclusion: don’t test more than required on target. Helps to test most of the code on the host (in a friendlier environment) Basic Technique n Fig. 10. 1 shows basic method to test on a development host. n Left side – target n Right side – host n Hardware and hardware-dependent code on target replaced by test scaffold code (emulator) n Input from keyboard, output to display (monitor) or to a log file n Divide software into 2 parts –hardware dependent and hardware independent with clean interface in between n However this is not always optimal. n E. g. suppose hardware dependent code only consists of hardware I/O calls to inp and outp. User required to simulate what actual hardware would return (for inp) and what to address to update in hardware on output (outp) n Difficult to test hardware code actually meant for the target on the host n Easier to test the test scaffold software on host instead. 5/31/2006 4

Testing on Your Host Machine (contd. ) 5/31/2006 5

Testing on Your Host Machine (contd. ) Calling Interrupt Routines n Interrupt routines normally divided in 2 parts – one dealing with hardware and the other with the rest of the system n For testing, structure ISRs so hardware-dependent part calls the hardware-independent part n Fig. 10. 4 shows an ISR to receive characters on a serial port n ISR v. Handle. Rx. Hardware deals with hardware, calls v. Handle. Rx. Byte (hardware-independent part) when it reads a character n v. Handle. Rx. Byte puts the character in a buffer, wakes command-handling task on carriage return, checks for buffer overflows etc. n Code is for p. SOS RTOS n v. Handle. Rx. Byte can thorughly test v. Handle. Rx. Byte for bugs but not the hardware-dependent v. Handle. Rx. Hardware 5/31/2006 6

Testing on Your Host Machine (contd. ) 5/31/2006 7

Testing on Your Host Machine (contd. ) Calling the Timer Interrupt Routine n Advisable to have test scaffold software call timer ISRs directly rather than making the calls automatic. n Better control on timer ticks (can decide when to call ISR) n Removes bugs due to timer ISR executing at the wrong time Script Files and Output Files n Script files make testing easy n Test scaffold reads script file and makes ISR or function calls as directed by it n Fig. 10. 5 shows a script file for a cordless bar-code scanner. n Each command causes test scaffold to call an ISR. n kt 0 – calls a timer ISR n kn followed by a number – calls a different timer ISR indicated number of times n mr – write data following it to memory, then call radio ISR n Purpose of file is to check if software works if scanner tries to link to a cash register, but only cash register from which it receives data (“beacons”) fails to respond to scanner’s requests for “association” n File checks if scanner retries its requests a certain number of times as it should. Note: ¡ ¡ ¡ Simple 2 -3 letter commands Comments allowed (anything following ‘#’ is a comment) Data valid in ASCII or hex. Data treated as ASCII until a ‘/’ encountered, after which data treated as hex 5/31/2006 8

Testing on Your Host Machine (contd. ) 5/31/2006 9

Testing on Your Host Machine (contd. ) n n Fig. 10. 6 shows sample output Note: input commands also copied to output file, hence input and resulting output intermixed 5/31/2006 10

Testing on Your Host Machine (contd. ) More Advanced Techniques n Often useful to have test scaffold software do certain things automatically. n E. g. calling printer ISR automatically on receiving a new line n Sometimes however it is required to turn this feature off. n E. g. putting call to printer ISR on hold to process another ISR (push-button) n Hence a switch required to enable or disable automatic calls when necessary. n In certain cases, test scaffold acts as communication medium between multiple systems Objections, Limitations and Shortcomings Engineers raise several objections on testing code on host instead of directly on target 1) Embedded-system code is very hardware-dependent n However code in most embedded systems has no direct contact with hardware – it only interacts with the microprocessor. 2) Building a test scaffold more trouble than it is worth n 2 responses to this objection ¡ ¡ 3) First – Finding bugs in lab takes too much time, so even if test scaffold turns up a few bugs it’s worth it. Second – Isn’t too much work. Only some effort in writing script files and capturing the output To use this technique you must have a version of RTOS that runs on your host ¡ Weak objection – most RTOSs run on multiple platforms (Windows, Unix etc. ) 5/31/2006 11

Testing on Your Host Machine (contd. ) Can’t test several important software characteristics on host like : - 4) ¡ ¡ n Software interaction with hardware: if software writes data intended for UART to wrong address you won’t detect it without the target Response and throughput: if code run in a different environment (different C compiler, microprocessor etc. ) these parameters will change. Shared-data problem: difficult to detect these on host. Portability problems: host and target may have many differences (host is big-endian while target little-endian etc. ). Can cause new problems to arise on target Conclusion: testing code on host might be troublesome, but more easy and efficient 5/31/2006 12

Instruction Set Simulators n n n Instruction Set Simulator (or simulator) – software tool that runs on host but simulates behavior of microprocessor and memory of target Build code using linker/locator but instead of target load it on simulator Keeps track of RAM and register values and mimics the microprocessor and memory GUI in most simulators similar to debuggers (can set breakpoints, single-step etc. ) Following are some of their useful characteristics: ¡ ¡ n Following are some of their shortcomings: ¡ ¡ n n Determining response and throughput: Though simulators don’t run at same speeds as the target, most will give statistics from which a reasonable estimate can be made Testing assembly code: Simulator runs the target instruction set so testing assembly code not a problem. Resolving portability issues: Same tool chain used for the simulator as for the target hence lesser portability problems Testing code dealing with peripherals built into microprocessor: Most simulators simulate target peripherals (timers etc. ). Shared-data bugs: Simulator will simulate the interrupts as and when needed, but it will be very difficult to create these bugs (so that they can be fixed) Other hardware: Can’t simulate custom hardware (ASICs, specialized radios etc. , however might be possible in future) Might not be possible to use previous testing methods (scripts etc. ) with simulators, so only use it to test startup code, ISRs etc. that can’t be tested by previous methods. Solve problem by reading scripts from character array in memory instead of a file. 5/31/2006 13

The assert Macro n n n The macro takes a single parameter If parameter TRUE – do nothing If parameter FALSE – crash program, usually with an error message like: ASSERT FAILED in file radio. c line 50 n n Used to check if certain conditions in code are true and to crash right away if they're not. Can then be fixed early on e. g. if a frame (inframe) is received on a network and if it should not be NULL at any point, use assert (inframe != NULL); n n n Useful to fix bugs early on instead of having program crash due to an undetectable cause (NULL pointers etc. ) Note: only helpful when testing on host (target usually doesn’t have monitors or displays) assert usually defined in file assert. h as follows: #ifdef NDEBUG #define assert(bool_expression) // Define it as nothing #else #define assert(bool_expression) if(bool_expression) ; else bad_assertion (__FILE__, __LINE__, #bool_expression); #endif 5/31/2006 14

The assert Macro (contd. ) n n n Define NDEBUG to prevent assert from crashing (when system testing finished and it is ready to be shipped to customers) bad_assertion can be modified so that assert also works on target, performing a different function instead of printing error messages. Following are a few suggestions: ¡ ¡ ¡ Disable interrupts then spin in an infinite loop. System will stop running and you will know something is wrong Make an LED blink. Copy the parameter values to another memory location so they can be checked later Copy address of instruction that called the bad_assertion to a specific memory location. Execute an illegal instruction 5/31/2006 15

Using Laboratory Tools Volt and Ohm Meters n Volt meter mainly used to test for broken leads, incorrect wiring, correct power supply etc. n Ohm meters used to test open or short circuits or connection between 2 points. n To use it turn circuit off, connect probe to the 2 points to be tested n If reading 0 ohms – points connected n Very high resistance (infinite) – points not connected n Intermediate value (bet. 0 and infinity) – points connected through another circuit that leaks current through them. Oscilloscopes n Commonly used to graph voltage vs. time n Extremely useful tool for debugging n Can be used to measure voltages instead of a voltmeter, test clock inputs, signal transitions etc. Logic Analyzers n Captures signals and displays graphs like oscilloscopes with following difference: ¡ ¡ ¡ 1) n Can track many signals simultaneously Only knows 2 voltages – VCC and ground Capture signals first and then display them Can have more complex triggering mechanisms can be used in either of 2 following modes: Timing Mode Analyzer is self-clocked ¡ ¡ ¡ Can find out if certain events ever occur. Can measure how long it takes for software to respond. Check if correct signal patterns are sent out or not 5/31/2006 16

Using Laboratory Tools (contd. ) State mode 2) ¡ ¡ ¡ Captures data when some particular event (like a clock signal) occurs Normally used to see instructions fetched by the microprocessor, data read/written to memory etc. Some analyzers disassemble binary instructions making it easier to understand what processor did instead of reading raw binary instructions In-Circuit Emulators (ICE) n Logic analyzers have following shortcomings ¡ ¡ n n n Can only see results but not actually debug (set breakpoints, single-step etc. ) Can only know memory contents if microprocessor reads or writes to them. Can’t see register contents Can’t examine anything if system crashes Can’t see instructions executed out of cache memory Used to emulate the microprocessor and replaces it Provides debugging capabilities. Can see memory contents even after a program crash. Some of them can capture a trace similar to logic analyzers Many have an overlay memory – memory inside emulator that replaces target memory Can specify which address ranges are read-only, read/write etc. Getting “Visibility” into the Hardware n Logic analyzers and emulators only provide information of signals that are attached. n Causes a problem with modern chips that have very small close-together pins. n Several vendors provide new attachments that connect to such pins n Another option – provide sockets for signals that you wish to probe (however takes up space on target) n Design a special circuit just for testing that is electrically equivalent to the target. However, there might be some differences between the special circuit and actual target n Can’t probe signals on ASICs n Can’t monitor signals on a RISC using a logic analyzer since it uses a very fast cache n RISC emulators only give an idea of instructions that are executed not the actual data read/written 5/31/2006 17

Using Laboratory Tools (contd. ) Software-Only Monitors n Monitors allow you to run software on target and still allows you to debug like an in-circuit emulator. n Has a small program that resides in target ROM. It receives software on a serial port or a network, copies it to RAM and runs it n Program referred to as a target agent, monitor, debugging kernel etc. n Another part of monitor runs on host, communicates with debugging kernel and provides a debugging GUI. n It also allows user to download compiled modules to target RAM n Some major disadvantages: n Requires a communication port on target n Most tools run only on standard hardware with standard communication ports, if target doesn’t conform to these, some modifications might be required n Most monitors incapable of capturing traces like logic analyzers Other Monitors n Two other monitor types other than software-only also widely used. n Differ in how they communicate with target n First uses a ROM emulator. Saves ROM space on target and allows several debugging options n Second uses a JTAG port n Some advantages of these two over software-only monitor: ¡ ¡ ¡ No communications port needed on target for the first type (ROM emulator) Independent of hardware design No additional software required on ROM 5/31/2006 18