Catching the Overrun
by Robert Ashby

Sometimes the hardest problems to find in a design are the problems that happen once in a great while and don't seem to repeat with any regularity. I have experienced such problems before because of overtaxing a processor. Most of my projects calculate all their timing off a single timing interrupt that is divided into different time slots for different processes in the design. If all my processes don't complete in the time allotted to them, I will see problems in feedback calculations and control calculations, and I will have communication problems.

Since there are many elements to a design, I first need to have a way to determine what type of problem exists and then see how to fix the problem. I may have had some suspicion that I was running into interrupt overruns, but I had to devise a plan on how to catch the problem. I've since taken a closer look at my current designs to see if they are on the verge of running into similar problems, and have found that I need to be more aware of how much free processing time I have to spare.

Interrupt processing involves stopping normal code execution and taking time to execute another section of code before continuing. This section of code is called the interrupt service routine (ISR). During the execution of the ISR, other interrupts are often disabled. An interrupt causes a problem if its service routine's execution time exceeds the time allotted before another interrupt is pending. For example, you might have a timer that triggers an interrupt once every 100 µs. If it takes 150 µs to service the interrupt (execute its ISR), you will have the next interrupt due 50 µs before you have finished the routine. Since interrupts are disabled until you finish the ISR, the next execution of the ISR will be 50 µs late. That might be acceptable. If subsequent interrupts don't take as long to execute, then the processor might have a chance to catch up without a serious problem. However, if the ISR continues to take longer than 100 µs to execute, then the interrupt lag will continue to grow.

Depending on the design, when a lag in the execution of the ISR continues to grow, it can present another potentially nasty situation. Once the interrupt lag grows to more than 100 µs, or if any individual interrupt takes longer than 200 µs to execute, then an interrupt isn't executed at all. The timer will set the pending flag for the interrupt sometime during the ISR, and then set it again sometime before the ISR execution has completed. Once you return from the interrupt, your processor recognizes that the pending flag has been set, but doesn't know that it was actually set twice. Therefore, it executes the interrupt only once and you have missed executing the other interrupt. If you are basing all your timing off this interrupt, this can spawn a plethora of hard-to-find problems.

There are various ways to catch a problem such as an interrupt overrun. I would like to mention a few that I've used to see when the problem exists. Adding up machine cycles for every instruction in a design that has several hundred lines of code and various paths of execution is impractical. I have often used a spare output pin temporally to toggle high upon starting the interrupt routine and then toggle low when I exit the routine. A scope on that pin will show you the approximate execution time of the routine. Watching the scope for a while can build your confidence of whether or not your routine is experiencing any overrun conditions. I would recommend, if possible, setting your scope to trigger on the positive width of the pulse being greater than the allotted time for the interrupt to execute.

If your interrupt is extremely fast, or if you are having a hard time seeing the wide pulse on the scope, then you could use a counter to look at ISR jitter. ISR jitter is my term for how the ISR execution time varies from one interrupt to the next. A software PWM is great at showing ISR jitter. What you have is code that sets up a counter at the same time that it sets an output pin high. The counter decrements once every interrupt until it reaches zero, whereupon the output pin is set low. The ratio of the counter value to the number of counts before the pin is set high again forms the PWM ratio. Here's a quick example using National COP8 code embedded within the ISR of a timing interrupt that trips every 100 µs.

;This section defines the width of the PWM
   ld   a,pulsewidth
   ifne a,#0
   dec  a             ;as long as pulsewidth != 0
   x    a,pulsewidth  ;decrement this down to 0
   ifeq pulsewidth,#0
   rbit 1,PORTD       ;shut off PWM output pin

;This section takes care of turning on the
; PWM output pin
;This section also defines the period of the PWM
   ld   a,periodcount
   ifne a,#0          ;as long as periodcount != 0
   dec  a             ;decrement periodcount
   x    a,periodcount ;store
   ld   a,periodcount
   ifne a,#0
   jp   nxt           ;exit if not time to reload
   sbit 1,PORTD       ;set pwm output high
   ld   pulsewidth,#80   ;set pulse width at 80%
   ld   periodcount,#100 ;then periodcount = 100
nxt:

		Click here to get your listing up.