| Chap. 1 | Chap. 2 | Chap. 3 | Chap. 4 | Chap. 5 | Chap. 6 | App |
5.0: Debugging Algorithms |
Debugging algorithms is much like debugging any computer program, and many of the same tools and techniques can be applied. The process is complicated by the fact that algorithms run in real time, so when you are watching them, there is no easy way to stop them to figure out what is going on. As we shall see, however, there are approaches to allow you to replay an algorithm as well as slow it down to aid in diagnosing its missteps.
The simplest and most straightforward debugging tool in most any language is the insertion of print statements at crucial spots. This is particularly easy in TMCALGO by use of nl_error() or its equivalent, msg().
The example below uses msg() to report the value of a particular variable:
State Motor_Init {
+1 > Motor On
+3 { if ( MtrRPM < 1000 ) {
msg( -2, "Motor RPM is %d", MtrRPM );
Validate Motor_Failed;
} else Validate Motor_On;
}
}
This might give us a little more information in the log than the state Motor_Failed would. The first argument to msg/nl_error defines the message 'level'. -2 is the first level of debug messages. Such messages will not be logged unless the algorithm is invoked with the '-l' option (which is usually asserted.) If we specified -3 instead, this message would require '-ll' to be logged, and so on.
This approach has also been used effectively to log key operating parameters during a flight, allowing the operators to assess the basic health of the system very quickly after a flight just by reviewing the log file.
Your algorithm has done something you don't understand. Now your run is over, and the data is logged. How can you figure out what went wrong?
The ability to replay algorithms against flight data is one of the great strengths of this architecture. During playback, you can fast-forward to an area of interest, then slow down the replay while viewing the instrument data screens and log files. This can be more effective than print statements, since you can immediately view almost all the relevant data.
In order to replay a run, you must first have logged
the data and issued a saverun or
reduce command. You will also need to
have prepared a playback
"doit" script. Assuming your playback script
is called "PBdoit" and your run was saved as
"010201.1", you can play it back by issuing the
command: "PBdoit 010201.1".
It is possible to combine playback with the printing techniques of the previous section by recompiling your algorithm. Provided you don't make changes that affect the procedural flow, the print statements should accurately reflect the data the algorithm saw when it made its decisions.
If playback leaves you still scratching your head, the last resort is to run your algorithm through a source code debugger such as the Watcom debugger, wd. The easiest way to do this is by using extract, which eliminates any realtime dependence and allows you to run the process in question without unnecessary display programs.
Before running with the debugger, you will want to
recompile your algorithm with some debugging information.
This will allow the debugger to display the C source code
and variables while it is executing. To do this, you will
first need to convince make to recompile the relevant
C module. The most crude way to do that is to
"Make clean", but that will require make
to rebuild everything, which can be pretty time consuming.
The best approach is to identify the name of the C source for
your algorithm and remove the corresponding object file. The
name of the main C source file for an algorithm is usually formed
by taking the name of the compiled algorithm and appending
".c" to it. Hence the source for hsimalgo
is in hsimalgo.c, and the object file you want
to delete is hsimalgo.o.
Once you have removed the object file, you need to
recompile with debugging enabled. The following command
should accomplish this for the hsimalgo case:
OPTARGS=g make hsimalgo
[ It is possible that you will run into trouble compiling with debugging enabled if your algorithm is large. If this is the case, the first thing to do is to make sure you are compiling using large model (set by adding MODEL=l at the end of your .spec file). If that doesn't help - or you were already in large model - then you'll need to compile in 32-bit mode. At this point, you may need professional help! ]
Assuming you have successfully compiled with debugging, you can now start up the debugger with the command:
extract 010201.1 "wd hsimalgo -psll"
As mentioned earlier, the quotes are very important, as is the '-p' option. Two l's will give you more potentially useful output in the log file, but your application may make more or less debugging output desirable.
The debugger will start up on another console. At this
point you will want to set a breakpoint or breakpoints in
the source file before starting to run. I find the easiest
way to figure out where to break is to open the source file
in an editor and search for the relevant statements. Most
of the C-style code from your .tma appears
more-or-less verbatim in the .c output, although
it is all rearranged considerably. You may need to spend some
time determining the general flow of the C program before you
are able to do very much in the debugger. It is also possible
that you might need debugging information for some of the
library routines as well. [ In this case, you definitely
need professional help! ].
One final tidbit of information which will come in handy is how to gracefully terminate an extraction that is underway so you don't have to wait for it to read through an entire flight's data:
sin gn' to determine the Experiment
name registered by rdr. This is usually
$Experiment.r, where $Experiment is defined in your
Experiment.config file.
Experiment=<exp> startdbr quit
| Chap. 1 | Chap. 2 | Chap. 3 | Chap. 4 | Chap. 5 | Chap. 6 | App |
Return to Manuals Guide. Written by Norton T. Allen
| last updated: Thu Jan 2 10:51:59 2003 | webmaster@huarp.harvard.edu |
| Copyright 2002 by the President and Fellows of Harvard College | |