Won't go back to SLEEP after 1st Interrupt

[jellis00]

Appreciate your inputs, but don't know what you mean by DT_Interrupts. Could you explain?
I am using the TMR0 overflow interrupt to count pulses up to a maximum of 256 pulses. That is adequate for my application. Why would I want to change over to TMR1 interrupt for 16 bits if 8 bits is enough?
I do understand your suggestion to reduce clock speed from my current use of internal clock at 4 MHz. However I don't want to add the costl of an external crystal and capacitors. Is there a way for me to reduce clock speed at the Main code just before SLEEP and then reset clock to 4 MHz when it enters interrupt?? My understanding from the data sheet is that the clock speed has to be part of the @ config statement that is read by the compiler and can't be changed during runtime.
Any suggestions from anyone on how to modify this code just before the @ SLEEP statment to reduce power would be appreciated. The current 400 uamps seems excessive for SLEEP mode....most posts indicate SLEEP mode for nanoWatt MCU like 16F690 should be more like a few uamps...not hundreds of uamps. >>>>

[jellis00]

I forgot to mention in my last post that the real problem I am looking for advice on is why my code doesn't put the MCU back into SLEEP mode after servicing the interrupts. Can anyone advise me? It is in SLEEP mode on power up, but after servicing the 1st interrupt will never go back into SLEEP mode as indicated by 400 uamps consumption.

[Jerson]

How about clearing the interrupt flags before you 'Sleep' ? Also, I think you need to read RB3 to clear the flag.

[jellis00]

Jerson, thanks for your comments. However, your comments confuse me slightly: 1) I thought my code does clear the mismatch condition for both types of interrupts at the end of each IF-THEN block for each interrupt before RESUME where i read the Ports (dummy = flush or dummy = TMR0);
2) I also thought my code does clear the intterupt flags for both types( FLUSH_INT_FLAG = 0 and TMR0_INT_FLAG = 0).
Your comment about reading RB3 also confuses me since I am not using the RB3 as an intterupt.
Can you please take another look at my interrupt service routine and clarify whether these coded statements are actually clearing the interrupts? Thanks!

[Jerson]

Well yes, you are right. I guess I wasn't thinking straight when I wrote this. You are indeed clearing the RA3 port(not RB3). TMR0 needs to be cleared by writing to the flag register which you seem to be doing. The dummy=TMR0 is not needed.

Only thing left would be to clear the flags before you 'sleep' rather than at the end of the interrupt. This will clear any conditions that occur between the interrupt end and going to sleep.

Sorry for confusing you.

[jellis00]

Thanks again Jerson. From everything I have read I thought the clearing of the mismatch and the clearing of the interrupt must occur before the RESUME statement at the end of an interrupt service routine?? Your suggestion to put them in the MAIN loop before the SLEEP statement is something I had not heard. I will try it to see.
I did find part of the problem. I commented out the @ NOP statement after the @ SLEEP statement and now the power consumption is as follows:
1) On Power up in the MAIN loop: 400 uamps
2) During ops after Interrupt in Int_Handler: 4 mamps
3) After completion of Int_Handlr (not sure whether program is at the SLEEP statement in the MAIN loop or not): drops back to 1.74 mamps.
But it is obviously not back into deep sleep since it didn't go to 400 uamps after the Int_Handlr.
4) If I remove power and then reapply power it goes to 400 umaps again.

Any other ideas on why it apparently isn't going into deep sleep after the Int_Handlr??

[jellis00]

I tried Jerson's suggestion to move the clearing of mismatch and interrupt flags to MAIN loop just before SLEEP statement instead of at the end of the Int_Handlr and it didn't work. It appeared to create continuous interrupts into the Interrupt handler without activation of any of the switches to do so.
When I put the clearing of mismatches and interrupt flags back at the end of the Int_Handlr just before RESUME the interrupts work correctly again.
Therefore, this suggestion to get the MCU back into deep sleep after servicing the interrupts didn't work.
Any other suggestions from anyone out there on how to get this back into deep SLEEP after the interrupts are services??