Rickta59 589 Posted January 26, 2013 Share Posted January 26, 2013 If the WDT triggers while in another ISR, it will save the SR at the time, which will be Active Mode, because all ISR's run in Active Mode. When the WDT ISR exits, it will only change the SR that was pushed onto the stack when the WDT was called. Control then returns back to the user's ISR. When that ISR exits, it will restore the SR that it saved at the time it was called, putting the system back into LPM. Consequently the call to __bic_status_register_on_exit in the WDT cannot restore the system to active mode. I don't think other ISR routines, like the watchdog, can interrupt your ISR unless you enable GIE inside your ISR. I could be wrong but that is my impression. In slau144i, page 38 it talks about the GIE being cleared "6. The SR is cleared. This terminates any low-power mode. Because the GIE bit is cleared, further interrupts are disabled." In slaa294a, page 3 it says something along those lines also: "Given this ability to change the power mode from the ISR, the developer can choose to implement the full functionality of the ISR within the routine itself, or use the ISR to wake up the processor and let the main loop handle all or part of the resulting functionality. Handling within the ISR ensures that the response to the interrupt event is immediate, provided that interrupts are enabled at the time of the event. However, while handling an ISR, interrupts are not enabled and will not be enabled until the ISR is completed. As a result, long ISRs may decrease system responsiveness. The developer must choose which of these options best fits the application." In a simple test I verified that if I put a blocking loop in my port ISR nothing else happens until the loop exits. -rick Quote Link to post Share on other sites
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.