topic How to Debug Unimplemented ISR in 8-bit Microcontrollers

How to Debug Unimplemented ISR

mjcoury — Fri, 10 Nov 2006 21:32:11 GMT

My Code is locking up and when I stop the code, I am sitting in the Unimplemented ISR, does anyone have any strategy for handling this? there isn't a full out clear all Interrupt flags I'm sure.....

Thanks in advance

Re: How to Debug Unimplemented ISR

Alban — Fri, 10 Nov 2006 21:56:18 GMT

Hi MJ,

To avoid being stuck or unwanted Reset, it's good practise to declare ALL interrupt vectors and have a proper function handling them.

You could have a generic function like:

Code:

#pragma TRAP_PROCvoid _dummyISR( void ){      ErrorCode = 1;}

That function would just report it to your system.

Or you consider having an unexpected interrupt is serious and therefore do something like:

Code:

#pragma TRAP_PROCvoid _dummyISR( void ){                                    /* endless cycle */    for(;;){    }}

If the COP is activated, it will generate a Reset.

By analyzing the stack when you stop the execution, you will be able to see the Return address.

This return address will tell you when the ISR was called and could help you find the source.

If you put a different function for each ISR (even if do the same thing), you will be able to get which interrupt occured by looking at the address of the current ISR being executed.

Hope this will help,

Cheers,

Alban.

Re: How to Debug Unimplemented ISR

bigmac — Sat, 11 Nov 2006 11:21:30 GMT

Hello mjcoury,

Your situation is not entirely clear to me. Does the "Unimplemented ISR" that you refer to consist of code that you have written, and does not exit? Or, after a break occurs, is the program counter set to an address within the interrupt vector block in flash, perhaps due to runaway code elsewhere?

Are you observing this problem during simulation, or with operation of the actual hardware? If the latter, are you actually setting a breakpoint to "stop the code"?

The method that Alban outlined will handle spurious interrupts that may occur, and is recommended, but I am unsure whether this is the cause of your current lockup problem.

Regards,

Mac

Re: How to Debug Unimplemented ISR

Geezer — Sat, 11 Nov 2006 12:01:08 GMT

You aren't necessarily sitting in your "Unimplemeted ISR". Every time you stop the code it will look like you haven't budged... although you did, for a VERY SHORT while.

Since you don't know the cause of the INT you are not servicing/clearing the source. The ISR will exit normally (unless your routine looks like ALBAN's second variant) and then come right back in a few cycles. A casdcade, an avalanche... and no stack crash to help you out!!

Al

Re: How to Debug Unimplemented ISR

mke_et — Sun, 12 Nov 2006 02:11:06 GMT

I'm not sure I get what you're implying right, but I can list what I do when I have problems like this.

First, I write a different vector handler for EVERY interrupt. Even if it does nothing but set a flag and then jump to a common handler. That way you can figure out what is really going on.

Secondly, I write all the stuff I put in my ISRs so that they are callable routines from foreground tasks. Once I have them working THEN I make them 'called' from the interrupt vector.

One thing to watch for is saving everything. Even if you don't think you're useing it, save every register. Once it's working THEN start looking for how to save space and compact things. I got burnt once on not saving the high byte of an index pointer that wasn't automatically saved by the hardware. Turned out it was 'assumed' that it would always be pointed to the base. If you touch it, save and restore it. If you use it, don't depend on a default.

Re: How to Debug Unimplemented ISR

mjcoury — Thu, 16 Nov 2006 07:49:47 GMT

the demo code i was using had a UnimpletementIsr()function that was solely

UnimplementedIsr(){
for(;{
}
}

When I added the FLL loop, I did not handle the ISR that could happen. So when I had a out lock condition, the code would get dropped into the loop. Only after I made a interrupt function for every interrupt case was I able to determine that it was indeed the FLL out of lock ISR.