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 wasexceptions.Note The processor ignores the value of PRIMASK in determiningwakeup 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 ..
Hello Andy,
& Thanks for responding.
Andy Neil said: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 ... )
d.ry said: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?
Yes, all interrupts enabled in the NVIC will wake up the core.
42Bastian Schick said:Yes, all interrupts enabled in the NVIC will wake up the core.
Does this, additionally , also mean any NVIC enabled interrupt will trigger ISR to be serviced, and then following it also wake up your main thread which is may be sleeping (may be because says, wifi is a "suggestion" to the processor..) after wfi instruction..?