>>Think about what is happening. You put the chip to sleep while
>still in the ISR,
>
>Again, I've never put the chip to Sleep inside a ISR, never in my life.

OK, I apologize if I miss understood what you were saying.

>What I an experiencing is that once I put the chip to sleep IN THE MAIN
>ROUTINE, then (when the Timer1 generates the interrupt) the ISR gets
>called, but once the RETFIE instructions executes, the chip returns to
>sleep, instead (as I was instead expecting) restart main program execution
>after the PWRSAV instruction (which is, again, in the main program,
>not in the ISR!).
>
...
>1. If the interrupt priority level for that source is greater than the
>current CPU priority level, then the processor will process the interrupt
>and branch to the ISR for the interrupt source.
>
>2. If the user assigned interrupt priority level for the source is less
>than or equal the current CPU priority level, then the processor will
>simply continue execution, starting with the instruction immediately
>following the PWRSAV instruction that previously put the CPU in
>Sleep or Idle mode.
>
>What the data sheet says though leads to think that the behaviour I am
>experiencing is normal, i.e. 1 would exclude 2. In 1 it doesn't say
>"after the ISR is terminated, the execution will continue from the
>instruction immediately following the PWRSAV instruction that previously
>put the CPU in Sleep or Idle mode.

Hmm, that is sneaky. I guess you will need to look at your priority settings 
...

I guess it allows one to do minor things in an ISR without invoking the main 
program until it just has to run and handle something. I haven't dug into 
the dsPic at all, so hadn't realised the main program priority could be 
changed. 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist