How to Debug Unimplemented ISR

[mjcoury]

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

[mke_et]

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.

[mjcoury]

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.

[bigmac]

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

[Geezer]

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

[Alban]

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.