Shawn,

Your problem is almost surely a result of the way you have structured your program.

After main() gets everything initialized, it spins in a do-nothing loop while all the action takes place within the interrupt handlers. This is almost always a poor approach, especially when the interrupt handlers are as involved as those in your program.

In general, interrupt handlers should be short, sweet, and to the point, leaving most of the processing to be done within a main loop of some sort that is straightforward and easy to understand. When everything is done within lenghty and complicated interrupt handlers, it's almost impossible to predict the control flow, and you wind up with interesting and mysterious problems exactly as you have seen.

Here's just one example of what I'm talking about. In your program, TimerZeroHandler() sometimes calls draw() right near the end. But wait: a different interrupt handler, DSPHandler(), also calls draw()!!! Since you've given DSPHandler() high priority, that means that it can interrupt the timer interrupt handler, possibly during the time that the timer interrupt handler is within draw(). Did you know that this was possible? Can you imagine what will happen when draw() is interrupted and then called a second time from a second interrupt handler? Can you imagine what will happen after the second handler returns? Can you imagine now how your Contact[] array might get corrupted?

If that isn't enough to confuse you, consider that draw() is also called by moveCursor() and enterPress(), both of which are called by a third interrupt handler, ButtonHandler(), which also has priority over the timer interrupt. Yikes!

Unfortunately, the only real solution for your problem is to completely restructure the program in a way that can be understood by mere mortals. From what I can gather, you basically want to respond to various system events by updating a display of some sort. It appears that the events are:

NEW_DSP_INFO_RECEIVED
UP_BUTTON_PRESSED
DOWN_BUTTON_PRESSED
LEFT_BUTTON_PRESSED
RIGHT_BUTTON_PRESSED
ENTER_BUTTON_PRESSED
---------------------
TILT_CHANGED
HEADING_CHANGED

It appears that the first six of these cause interrupts, and that the last two are detected by polling. If all that is true, then here is one way you could proceed:

1. Implement a FIFO event queue that's long enough to hold the maximum number of outstanding events you ever expect.
2. Rewrite your interrupt handlers so that instead of trying to process the events themselves, all they do is place a notification that the events occurred into the event queue.
3. Rewrite your main loop to work something like this:
   
   

Doing all that should vastly simplify your program and make it much easier to debug. Here are a few other miscellaneous tips:

• Get rid of the delay loops in your program. Base any needed delays on a timer interrupt instead.
• Replace the "magic numbers" in your program with #defined constants. The code in DSPHandler() that parses the DSP data is particularly bad in this regard.
• Consider using sscanf() to parse the DSP data.
• Try to eliminate all the global variables from your program.
• Try to keep all the interrupts at the same priority. Then you won't have the confusion of interrupt handlers that interrupt other interrupt handlers.
• Store the display initialization and refresh commands in arrays, then call wrtCommand() repeatedly from within a loop instead of writing 20-30 individual wrtCommand() calls.

-- Russ