Transcript Introduction to Programming - Louisiana Space Consortium

System Testing and Debugging
Programming Unit, Lecture 7
LSU 11/01/2004
System Testing and Debugging
1
System Testing and Debugging
•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 25o C
•A test plan should include tests that verify the required functions
over the range of conditions the system will encounter.
LSU 11/01/2004
System Testing and Debugging
2
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.
LSU 11/01/2004
System Testing and Debugging
3
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.
LSU 11/01/2004
System Testing and Debugging
4
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.)
LSU 11/01/2004
System Testing and Debugging
5
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.
LSU 11/01/2004
System Testing and Debugging
6
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.
LSU 11/01/2004
System Testing and Debugging
7
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.
LSU 11/01/2004
System Testing and Debugging
8
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
LSU 11/01/2004
System Testing and Debugging
9
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-todigital converter.
•You should already be familiar with the ADC. In this activity you will
chose components to set the gain of amplifier U6.
LSU 11/01/2004
System Testing and Debugging
10