• State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 347 subscribers
  • Views 11265 views
  • Users 0 members are here
Options
Related
How was your experience today?
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?

d.ry

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
  • 0 in reply to Andy Neil
    Andy Neil said:
    this unknown chip maker supply examples of waking its device from sleep

    Err,  I would say, in principle TI's idea on this SoC is for users to not program registers directly, and prob even less so invoke asm or pseudo instructions themselves ... It' suppose to be "simple", including power management in particular.
    But this is an exercise I'm doing.

    And since the SoC is CM4 based, it's thus irrelevant what they / TI want you to use : the chis is Cortex, and registers are there, so are the instructions  :)

Reply
  • 0 in reply to Andy Neil
    Andy Neil said:
    this unknown chip maker supply examples of waking its device from sleep

    Err,  I would say, in principle TI's idea on this SoC is for users to not program registers directly, and prob even less so invoke asm or pseudo instructions themselves ... It' suppose to be "simple", including power management in particular.
    But this is an exercise I'm doing.

    And since the SoC is CM4 based, it's thus irrelevant what they / TI want you to use : the chis is Cortex, and registers are there, so are the instructions  :)

Children