9 times out of 10, my program awakes fine (IOC interrupt related), but....

[HankMcSpank]

This is a tricky one that I can't get to the bottom of....I'm at a loss now and throw myself open to the forum for help!

Ok, here's what I'm doing, I'm putting a PIC to sleep, just before doing so, I enable IOC DT interrupts....

IOCAF = 0                    'clear the interrupt flag
@ INT_ENABLE  IOC_INT   ' enable IOC interrupts
PAUSE 50                     'wait a little 
@ sleep                       ' put the PIC to sleep

Ok, so far so good, my PIC goes to sleep

So now when a switch gets pressed. the PIC gets woken up by an IOC Interrupt - I have a fair splattering of debug lines in the interrupt routine - I can see the program enter the IOC Interrupt routine (debug line at the top of the routine) & exit (another debug line at the end of the routine) - again so far so good.

Now from my weak understanding of waking from sleep, I believe the program picks up from the line of code immediately after the @sleep line (above), so here's what follows the @sleep line in my program...

@ sleep                       ' put the PIC to sleep (ie same entry as above, shown here to show the flow of things)

'here's what follows & should be where the PIC picks up...

pause 5
TrisA.0 = 0 ' make the nominated debug pin an output
debug "awake",13,10

So when all is working well, with the PIC being asleep, after a switch is pressed (to wake up the PIC), I should see my IOC interrupt 'entry' debug line, my IOC interrupt 'exit' debug line & then the word "awake" (ie the line of code immediately following the @sleep command)

So what's the problem?

Well as my thread title suggests...it's not robust - if I press the switch to wake the PIC ....about 7-10 times it wakes up fine on the trot, but then a problem occurs & my program appears to go nowhere(!) - the last thing debug line I see on my screen is my IOC interrupt 'exit' debug entry.....and nothing else after that (in other words I don't see the debug line "awake" onscreen)

I have no idea where my code is (ie where the code is at!)....any ideas how to debug this one?

I'd appreciate a bit of input as I'm worn out!!!

[HankMcSpank]

Hmm, it seems I'm a danger to myself - knowing full well that the next post on this thread would be along the lines of "Hank, post your code up"...i stripped my humumgous bloaty code back to something that could would be easy on the eye ....and you know what comes next....yep, the stripped back code worked 100% of the time!

So it transpires (to me at least) that I apparently can't use Gosubs whilst in DT's interrupt routines (or at least gosubs that go outside the DT interrupt routine) ....or maybe I should rephrase that - I can use Gosubs in DT interrupts, but I get very erratic results!

What I learned today....

1. Probably best not to use Gosubs when in a DT interrupt routine.

2. If you do...everything will compile...and 80% of the time it'll work - it's that pesky 20% that's the issue (& that lost me a whole day trying to debug!)

Now I know all you old hands, muttering "tsk.....n00bs" - but hey, at least I owned up!

[cncmachineguy]

Hank, while I am no old hand, may I remind you there are things we can do- but shouldn't. Like bungee jump or sir jump. I guess this also includes gosubs. Btw, for he benefit of those reading, it's not limited to gosubing from DT_int, it's any interrupt.

Thanks for sharing Hank, we all learn from others mishaps.

[HankMcSpank]

Thanks bert :-)

Ok, I've removed all the gosubs from the interrupt routine, but I'm still getting erratic results...I kinda know what's not causing my PIC to go to sleep , but the workaround is ugly.

I think I'm hitting diffs with nested gosubs. Imagine this scenario (this is just high evel *not* my actual code - just to get my problem across)...

loop1:
if pattern = 2 then goto loop2
IF sleep_flag = 1 THEN GOTO SLEEP_ROUTINE
pause 10
gosub decrease duty
gosub select_LED1
pause 10
gosub increase_duty
goto loop1:
'
loop2:
if pattern = 1 then goto loop1
IF sleep_flag = 1 THEN GOTO SLEEP_ROUTINE
pause 10
gosub decrease duty
gosub select_LED2
pause 10
gosub increase_duty
goto loop2
'
SLEEP_ROUTINE:
debug "PIC off to sleep",13,10
pause 200
@sleep

' program continues here afteran IOC interrupt....
pause 100
debug "PIC awake",13,10

IOC_Int:
@ INT_DISABLE  IOC_INT

if sleep_flag = 1 then ' if we wake from asleep, this flag will be set still need to clear it & retun to the main program
sleep_flag = 0
goto INTERRUPT_END
endif

LOOP3:
        IF SW1 = 0 THEN 
        COUNT3 = COUNT3+1
        IF COUNT3 >300 THEN      'if Sw1 held for 300mS then set sleep_flag
        SLEEP_FLAG =1 
        goto INTERRUPT_END
        ENDIF
        pause 1 
        GOTO LOOP3
        ENDIF

if pattern <2 then    pattern=pattern+1  'cycle between pattern1 & pattern 2
else
pattern=1
endif

INTERRUPT_END:
COUNT3 =0  
while sw1=0
wend
PAUSE 180 
IOCAF = 0         'CLEAR THE INTERRUPT FLAG
@ INT_ENABLE  IOC_INT
'**************
@ INT_RETURN

It seems the interrupt routine (or program!) doesn't like the highlighted Gosubs in the loop1 & loop2 - if I remove the gosubs & instead locate the actual code contents of the gosubs in each loop - then everything is dandy (i.e. the PIC always goes to sleep & awakes fine) , but if I have gosubs in those two main loops - it looks like the interrupt routine (or some other aspect of my program) doesn't return to the main two loops & then trap the sleep_flag being hit! (the problem here is that by not using gosubs I run out of program space *very* quickly!)

What am I missing here?

[HenrikOlsson]

Hi,
First, I don't understand why you shouldn't (can't) be able to use GOSUB inside or outside of a DT-INTS ISR as long as you RETURN (as you should with ANY GOSUB), anyone care to elaborate on the reason you say you should never do that? Yes, the stack is limited, so you need to makes sure it doesn't overflow if you happen to get an interrupt when you're already into x nested GOSUBS but as far as I can see it should work.

Hank, I'm not syaing I have a solution for you but is seems to me that your program can "fall thru" into the ISR by itself. It wakes up, DT-Ints trips and jumps to the ISR, the ISR runs and the then it returns to where it woke up, which is right before the ISR so the ISR runs again. It hits the @INT_RETURN (by the way, there seems to be a missing underscore in your code?) and it returns to "somewhere". I think you need a Goto Loop1 or whatever right after the DEBUG satement - but I just had a quick look at it so I may be missing something.

/Henrik.

[mackrackit]

Golden rule for interrupts.
Once in get out as quick as possible.
My guess is GOSUB a time or two will violate the golden rule.

Yes, seeing the whole code could help