1. LSU 11/01/2004System Testing and Debugging1 Programming Unit, Lecture 7

2. LSU 11/01/2004System Testing and Debugging2 Why test? To see if “it” works, of course. Avoid surprises that tend to occur at the worst possible time. Mission failure may be dangerous or expensive, but it’s always embarrassing. Proper testing requires knowing the expected results. Formal tests should have well defined performance requirements. For example, VCC should be 5.00V +/- 0.25V at 25 o C A test plan should include tests that verify the required functions over the range of conditions the system will encounter.

3. LSU 11/01/2004System Testing and Debugging3 Hardware vs. Software BalloonSat based systems will have both hardware and software components. Frequently the individual components will have been designed and implemented by different individuals or teams. The Hardware Team will claim the problem is Software. The Software Team will claim the problem is hardware. For really nasty problems the Hardware and Software Teams may form an alliance and pronounce that the problem is Management. In the end though, Hardware and Software will have to work together (and with others) to design, build, test and deliver a successful project.

4. LSU 11/01/2004System Testing and Debugging4 Design and Test Design: A poorly designed system will fail system tests. Many patchwork “fixes” may not yield a satisfactory deliverable. Avoid the inevitable crises by “doing it right the first time”. Documentation: Specifications, design documents, assembly drawings, operating instructions. Documentation will be critical for those building, testing and using the system. Compatibility: Does the system interface properly to external devices? Have all issues of safety and interference been resolved? Have the Interface Control Documents been followed? Test Plan: Have all design requirements been met and verified? Find out before the system is deployed.

5. LSU 11/01/2004System Testing and Debugging5 Debugging and Troubleshooting Tests have revealed one or more failures, now what? The nature of the failed tests and the results may lead you to a root cause or may suggest yet more tests that should be done. In any case, debugging and troubleshooting require careful observation and logical thought. It is mostly (or should be) an exercise in logical reasoning. Read physicist Richard P. Feynman’s account of how at the age of 11 or 12 it was noted by his neighbors that he “fixed radios by thinking about them”. He paced back and forth thinking of the observed symptoms and deduced the possible causes of such behavior. (The story is told in “Surely You’re Joking, Mr. Feynman: Adventures of a Curious Character” by Feynman, et al.)

6. LSU 11/01/2004System Testing and Debugging6 First troubleshooting steps Are you debugging a new system or circuit that has not yet been proven to work? You may need to review the design or assembly for errors. Are you dealing with a system or device that once worked but has now failed? What has changed since it last worked properly? Can you undo the last change to see if operation returns to normal? Never assume the basics. Do you have power to the systems? Is it turned on or enabled? Check power supplies, voltages, indicator bulbs, fuses. Eliminate the simple failures first. (Is the landing gear stuck or do you only have a defective gear-down indicator lamp?) Learn how to use multimeter, oscilloscope, other test equipment before you need it. Don’t wait until you’re on the flight line trying to launch.

7. LSU 11/01/2004System Testing and Debugging7 Troubleshooting techniques Shotgun Approach: Don’t aim at any specific component, just replace everything with spare parts. Can be a quick fix if your lucky. You risk damaging your spares, bending IC pins or causing other problems. Worst case: you don’t fix the problem and you now have spares that are suspect. Divide and Conquer: Approach the system as a collection of modules (hardware or software). Whittle the system down to manageable pieces and attack each module separately. The binary search. Logical sequential: Divide and conquer from input to output a stage at a time. Stages might be circuits, subassemblies or program subroutines.

8. LSU 11/01/2004System Testing and Debugging8 Test Points Test points may be designed into hardware for convenient measurement of critical signals, power supply voltages. Some test points are intended for injection of calibration signals. Even if there are no test points designed into the Device Under Test you can define your own once you study the system and can project the expected measurements at user-defined test points. Logical locations for test points are inputs and outputs of functional blocks such as amplifiers, converters (A-to-D, D-to-A, V-F, etc), comparators, or digital logical blocks. Subassembly power input terminals are important test points.

9. LSU 11/01/2004System Testing and Debugging9 Test points for software “Test points” can also be helpful for software troubleshooting and debugging. Create temporary Breakpoints to halt program execution so that registers, variables or memory can be examined. In PBASIC, use the STOP instruction. Just be sure to remove the STOP once debugging is complete! Place DEBUG instructions to print variables to the screen. Use DEBUG to print flags as subroutines are entered or at points of conditional execution. Helpful in seeing program flow. For example DEBUG “entered subroutine Get_XY_coord”, CR

10. LSU 11/01/2004System Testing and Debugging10 Activity In the final Activity of the Programming module you will use BalloonSat to measure and record temperature. The AD780, U5, precision voltage reference chip contains a temperature sensor. The voltage output from this sensor is amplified by opamp U6 and can be connected to CH3 of BalloonSat’s analog-to- digital converter. You should already be familiar with the ADC. In this activity you will chose components to set the gain of amplifier U6.