WFI Instruction

You can exit the low priority interrupt handler, back to the main loop and execute WFI in your main loop. As you already know, this will place the processor into standby mode. It will execute no further instructions until an interrupt happens.

Alternatively, you can set the SLEEPONEXIT bit, wither within the handler or before it is entered. When the handler exits, the processor will automatically enter standby mode and wait for an interrupt to restart execution.

There is a paper I wrote on some of these techniques, based on a presentation from Embedded World 2015. You can find it here.

Hope this helps.
Chris

You can exit the low priority interrupt handler, back to the main loop and execute WFI in your main loop. As you already know, this will place the processor into standby mode. It will execute no further instructions until an interrupt happens.

Alternatively, you can set the SLEEPONEXIT bit, wither within the handler or before it is entered. When the handler exits, the processor will automatically enter standby mode and wait for an interrupt to restart execution.

There is a paper I wrote on some of these techniques, based on a presentation from Embedded World 2015. You can find it here.

Hope this helps.
Chris

Hi, @Chris Thanks for your answer. Will there be any time delay since the CPU have to switch between Idle mode and active mode and will it affect the other peripherals connected to the controller and GPIO Pins ?

In fact I can achieve the same by giving a maximum delay also(to wait till the interrupt to occur).

or by polling some flags(flags sets when interrupt occurs). what do you suggest ?

There is no penalty for entering a leaving standby mode. If you enter deeper sleep modes, though, there will obviously be a penalty associated with saving and restoring system state. But, no latency for standby mode at all.

Entering and leaving standby mode should not affect the operation of any other peripherals as the system remains powered. It is only the core clock which is halted.

Yes, you could implement a delay-based or polling-based solution but both of those options will consume more power as the processor will continue to run while waiting. Most people would not regard that as good practice in developing a system like this.

One point, though, is that if there is any doubt that the interrupt you are waiting for will eventually happen, it is worth implementing some kind of watchdog timer which will interrupt and wake up the system after some maximum length timeout if nothing else has happened. Otherwise, y ou run the risk of the system never waking up if the interrupt you are waiting for never happens. This would be good defensive programming practice.

Hope this helps.

Chris

Thank You Chris.

Hi, @Chris

Can is use WFI inside an ISR to wait for a higher priority interrupt to occur ?

I don't believe there is any fundamentals, architectural reason why you should not be able to do this. However, I would not recommend it. If you choose to stop the processor in this way, all exceptions of lower priority will be blocked until you exit the exception handler. That is almost certainly not what you want. If you want to achieve the same effect, better to set the SLEEPONEXIT bit and then exit the exception handler. The processor will then exit the exception context and immediately sleep.

Hope this helps.

Chris

Hi, Thanks for your response.

This is what I need because I'm executing WFI instruction on the lowest priority interrupt service routine (occur continuously) which drives my code. I actually want to block the code until I get a response from the peripheral device(the expected interrupt after giving a command to the peripheral device - GSM) or else it would affect further progress in the code as I'm setting few flags based on this expected interrupt(like checking if the GSM is Offline or Online etc).