This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

When does a Cortex Mx wake up from "wfi" ? Is it configurable?

Hello,

Question about the "hint" instruction  - WFI.

The armv7m arch manual (i'm using DDI0403_B, latest?) says it will come out of the suspended / low-power state if:

• A reset.
• An asynchronous exception at a priority that, if PRIMASK was
exceptions.
Note
The processor ignores the value of PRIMASK in determining
wakeup event.

• If debug is enabled, a debug event.
• An IMPLEMENTATION DEFINED WFI wakeup event.

and I don't understand all of it.  

Point 2 above: Say I start clean from reset with minimal setup, and (pseudo code) in my main is      while (true) { __wfi;  /* do stuf .. */ }  , and I 've left all priorities as default after reset, non-configured un-altered.  Are _any_  of Cortex non-NMI/non reset exceptions suppose to wake up my main?   i.e, SysTick,  Svc, PendSv ? 
How about external exceptions or interrupts that I've may have enabled through NVIC ? 
I'm using a CM4 based chip, and , I may have observed it wrong but it seemed to me that my main does not wake up on a peripheral interrupt, and out of the internal exceptions it wakes up on SysTick and SVC, but not on PendSV (it _seems_ ..)

Can an implementation change which exceptions will wake up the processor which is in sleep by wfi?

The part which says "implementation defined" WFI event: will those usually be expected to be specified by the tech ref manual or datasheet for the chip/ SoC? Because, I'm looking at the manual for this chip and I see no mentioning of the WFI & reference to this Implementation Defined part.

Also, Is it configurable at all, which interrupts / events would cause it to wake up from WFI ...?     (I would want to ask about WFE as well, but I rather sort one out first).

Is actually using / relying on wfi any good at all for relying to wake up your main thread to check what just has happened ..

Parents
  • Hello Andy,

    & Thanks for responding.

    if the interrupt is coming from some vendor peripheral (outside the Cortex core), then that peripheral will also need to be correctly configured, enabled

    I should have started by writing, the interrupt that is coming from external vendor - yes outside of Cortex core as you wrote - I do not have particular issue with in itself : it' is coming, and it is handled by my code, in the interrupt mode.

    What I'm not sure about is whether this external vendor interrupt, even if configured correctly, will / or suppose to wake up my main processor thread - i mean , not in IRQ state / ISR.   Part of my confusion is , could that be part of what the arch spec calls "implementation defined " wake up "event" ?    Or is that reserved for something else?

    And how would one generally find out which is that implementation defined event to wake up from while in wfi?

    Going back to my I guess badly worded question :  is WFI always then suppose to wake up on all enabled internal Cortex exceptions /interrupts, and those external / non-Cortex specific from vendor or SoC maker?

    As I wrote in my OP, I _may_ have observed it wrong way, but I saw that my configuration _may_ have been setup such that my main thread does not wake up while on wfi if the external peripheral interrupt ticks  - and I mean i have an ISR handler code which gets invoked & runs, but not the main code - but, on the other hand,  main always resumes/unlblocks from wfi after every SysTick interrupt is handled, without me doing anything special.

    (But as I wrote originally , and now, it's _may_. And I'm likely also not following the chain of events right. It _may_ be, with default priorities, what happens is external ISR followed by SysTick ISR and then main wakes up. I may be never caught case where it would have been woke up if the external ISR happened before/ not at same time as my SysTick ... )

Reply
  • Hello Andy,

    & Thanks for responding.

    if the interrupt is coming from some vendor peripheral (outside the Cortex core), then that peripheral will also need to be correctly configured, enabled

    I should have started by writing, the interrupt that is coming from external vendor - yes outside of Cortex core as you wrote - I do not have particular issue with in itself : it' is coming, and it is handled by my code, in the interrupt mode.

    What I'm not sure about is whether this external vendor interrupt, even if configured correctly, will / or suppose to wake up my main processor thread - i mean , not in IRQ state / ISR.   Part of my confusion is , could that be part of what the arch spec calls "implementation defined " wake up "event" ?    Or is that reserved for something else?

    And how would one generally find out which is that implementation defined event to wake up from while in wfi?

    Going back to my I guess badly worded question :  is WFI always then suppose to wake up on all enabled internal Cortex exceptions /interrupts, and those external / non-Cortex specific from vendor or SoC maker?

    As I wrote in my OP, I _may_ have observed it wrong way, but I saw that my configuration _may_ have been setup such that my main thread does not wake up while on wfi if the external peripheral interrupt ticks  - and I mean i have an ISR handler code which gets invoked & runs, but not the main code - but, on the other hand,  main always resumes/unlblocks from wfi after every SysTick interrupt is handled, without me doing anything special.

    (But as I wrote originally , and now, it's _may_. And I'm likely also not following the chain of events right. It _may_ be, with default priorities, what happens is external ISR followed by SysTick ISR and then main wakes up. I may be never caught case where it would have been woke up if the external ISR happened before/ not at same time as my SysTick ... )

Children