Hardware Reference
In-Depth Information
V CC
10 k Ω
SW DIP-8
HCS12
PA0
PA1
PA2
PA3
PA4
PA5
PA6
PA7
Figure 4.19 Connecting a set of eight DIP switches to port A of the HCS12
4.12 Tips for Program Debugging Involving Subroutine Calls
Program debugging becomes much more difficult when a program calls subroutines. To
make program debugging easier, we test each individual subroutine thoroughly to make sure
each subroutine works correctly and returns to its caller.
4.12.1 What to Do When the Program Gets Stuck
It is a common problem that the program gets stuck in one of the subroutines and cannot
return to the caller. The procedure for debugging in this situation is as follows:
Step 1
Write an instruction sequence to call each subroutine to find out if the program gets
stuck in that subroutine. This can be done by setting a breakpoint at the instruction
immediately after the jsr or bsr instruction. One can use the D-Bug12 asm command
to find out the address of the breakpoint to be set. In CodeWarrior, this can be done
much easier.
Step 2
Find out why the program gets stuck in the subroutine. There are at least the following
four causes:
1. Forgetting to restore registers pushed onto the stack before returning to the caller
2. Forgetting to deallocate local variables before returning to the caller
3. Some infinite loops in the subroutine
4. Calling other subroutines that do not return
The first two causes can be identified by simply looking at the program. To determine
if the program gets stuck because of forgetting to restore registers, check to see if the sub-
routine has several push instructions at its entrance. If it does, then it should have the same
number of pull instructions in the reverse order before it returns (using the rts instruction).
For the second cause, check to see if the subroutine has the instruction leas -k,SP to allocate
 
Search WWH ::




Custom Search