Interrupts and stack

[Alexey]

Hello All,

Maybe someone could advise what are most common mistakes in building a program driven by interrupts. I am playing with PIC18f24k22 which should have big enough stack but so far my attempts to use INT0...INT3 did not have much success as I always stick into stack overflow reset. Checked if all my gosubs end with returns and it looks like they do. Global int bit is also set and flags cleared but as soon as I enable INTS and press button causing external INT, stack overflows. The code is pretty large to post here but maybe someone could advise what to read about common mistakes on this topic. Does it make sense that I use Long variables? I tried to comment pieces of code and it looks like at some point when it becodes critically large the problem appears... Must say I have many subroutines but the problem often appears when the executing piece of code not too deep in them and often when no subs surrently running

Must say I felt more comfortable with PIC16 which have circled stack so if a leakage like exiting a subroutine without "return" occurs, it does not make any problem. It looks like it is a different story with PIC18

Thank you!

[Bruce]

If your code is large, then post it as an attachment VS inline. But how do you know this is a stack overflow reset?

A single interrupt event shouldn't cause a stack overflow, but we have no way of knowing what's going on, or offering much help, without seeing the code you're having problems with.

[cncmachineguy]

Are you RETURNing from the ISR or RETFIEing? There is a special return from interrupt to use just for that.

[Charles Linquis]

You can read the Stack Pointer 'STKPTR' at any time and see what is going on.

Before I put any code 'in the can', I print out the stack pointer value at the top of my main loop and try all sorts of
things. If the value ever gets greater than zero, I know I'm in trouble.

[Alexey]

Thank you Gentlemen,

Thank you,

Reading the stack in the top of the Interrupt handler I learnt that it sometimes was above 150!

Yes, I use RESUME for returning from the interrupt handler. I was thinking this was a stack problem because when I switch the fuse for ignoring the stack overrun/underrun it does not reset (but still does not work properly) The problem accurs when the code jumps into the interrupt and I found where my stupidity was. I used gosubs which jump from the interrupt handler into ENABLED area. DISABLEing that portion of code fixed the problem. In fact the interrupt handler was calling itself again and again while in the external subroutine with enabled interrupts.

On this point of view if the stack is not rounded on these controllers I am not sure if I can use RESUME LABEL or not on tis particular controller - if I do not resume back into subroutine which was interrupted, I may have leakage of stack space again. Do you know how PICBASIC handles the RESUME LABEL? does it clear the stack from the previous broken calls?

Thank you,

[cncmachineguy]

Can you post your code? You really should never gosub or goto out of an ISR. It just sets you up for bad hard to find problems. While I am not sure, I get the feeling you are using on interrupt. You can maybe get away with this in this case, but as you start using interrupts (DT_INT or ASM) this will cause you un known problems.

As for the circular stack, that would just mask the problem. You code may appear to be working, but in fact may be doing lots of just looping willy-nilly until it finds the correct spot again.

Remember even a broken clock is correct twice a day.

[Alexey]

Hello Bert,

Yes, you are right, I am using "ON INTERRUPT" and from the interrupt handler I accessed a subroutine placed outside. Putting "disable/enable" around that subroutine fixed the problem, but I will just copy that piece of code into the interrupt handler to avoid further problems. So far I am not ready to insert ASM code, so everything is in PICBasic.

I like Charles idea to put stack value onto display in the beginning of the main loop to check if there is a problem. In my case I needed it in the interrupt handler (where I now have this value slightly above zero) but the test of the main loop for zero value is just great!

Thanks, as usually you all are very helpful. Hope some day I will be able to help others too :)