EE-218 Lab News

Lab 10

System Debugging

Before the Lab

When a computer program is written, it is necessary not only to choose the proper instructions but also to properly format each instruction statement. Assemblers and compilers will generate syntax errors when processing source program statements that are improperly written, but even when the programs are edited to eliminate all syntax errors, there is no guarantee that the program will run successfully or function properly. Only executing the instructions can test the program's logic. A newly written program is likely to have mistakes and therefore must be tested carefully before attempting to let it run by itself. Systems like the HC11-VDK and the Axiom boards with their debugging features are usually used so that the problems can be analyzed. The program can be stopped and corrected when something is wrong. System debugging is the name given to this process. It verifies not only that the program does calculations and handles data correctly but also that the software properly controls the external hardware.

One of the most common tools in system debugging is the use of a 'Monitor' program in ROM. By now, you are familiar with both monitor programs used by the Axiom boards, namely the BUFFALO. They contain many features for program development and analysis. Following are some of the most important facilities used in debugging:

1. Break point setting.

2. Ability to test a subroutine by 'CALLing' it directly from keyboard.

3. Memory display and edit.

4. Registers display and edit.

5. Tracing through a set of instructions.

It is interesting to know how the monitor handles the tracing and break points. Software interrupts can be used to implement these facilities.

For the trace command, the Output Compare 5 (OC5) interrupt can be used to time out after the first cycle of the first Op code fetched. To use this feature to examine a program's operation, the PC is set to the instruction to be tested, and a T command is then entered to execute the instruction. This monitor program command serves to set up the OC5 timer count values and enable its interrupt to occur after a prescribed number of clock cycles. This is the exact time required to run through the monitor routines and start executing the user's instruction. The microprocessor will run the instruction pointed to by the PC at normal clock speed and then stop to service the OC5 interrupt. The service routine gets the registers contents from the stack to display them. It then reenters the monitor command loop, displays the prompt, and waits the next command. An option can be added to this feature to run a specified number of instructions before getting the interrupt.

For the break point facility, the monitor temporarily inserts a software interrupt SWI instruction in place of a user's program instruction, and saves the code that was in that location. When this SWI instruction is reached, an interrupt service routine is called. It displays the content of the registers and puts back the user's instruction in place so that, when checking the code in memory, the user finds its code and not the code for the SWI.

In the Lab

You will be given a software code along with the specification of typical inputs and expected outputs. Your task will be the following:

• To devise test cases to debug the program. You should indicate to your T.A. the reason for selecting those test cases.

• Use the debugging facilities provided by monitors to fix the program's problems. You have to take notes when you are solving those problems. Provide a systematic way of debugging.

The main objective of this lab is to learn how to systematically debug a program and prove that it is working according to the specs given. Try to use test cases that are not trivial (e.g. for a sorting program you will need to try its output if the list to sort is empty, if the list has only one number, if the list has negative and positive numbers, if the list has the same number repeated several times, etc.).

After the Lab

Explain the program that you were to debug, and the approach you used to fix it.

Include a list of the test cases you used.

Can you think of other facilities that could be added to the BUFFALO monitor (considering the size of memory available) to make the debugging easier?

Assume that you are supposed to talk about very common mistakes you and your classmates have made in the lab assignments. What are those? Besides code inspection, what helps you find the errors? Can you provide a systematic approach to finding programming bugs?

          TABLE 1.  BUFFALO Monitor Program Commands

Several subroutines exist that are available for performing I/O tasks. A jump table has been set up in ROM directly beneath the interrupt vectors. To use these subroutines, execute a jump to subroutine (JSR) command to the appropriate entry in the jump table. By default, all I/O performed with these routines are sent to the terminal port. Redirection of the I/O port is achieved by placing the specified value (O=SCI, 1=ACIA) into RAM location IODEV.

Utility subroutines available to the user are as follows:

Utility jump subroutines for performing I/O tasks are shown below. These subroutines are in ROM and are programmed as jumps. To use the jump subroutine, execute a JSR to the applicable address shown below.

Copyright © 2003 Vanderbilt University