Good grief. The app that I'm testing calls WFE, not WFI.6.2.3.1 says that it won't transition to a P0.m state unless you WFI on the cores, but I think that's a typo for P1.m as it says "Low Power (P0.m)" state and elsewhere says "P.1m" for Low Power.
I remember being surprised that the datasheet chapter about POWMAN specifically mentions WFI as a step in power state transitions, because it implies by omission that WFE doesn't work for that purpose. In my head, since WFI and WFE have identical effects with respect to processor sleep, it seemed strange that one but not the other has a role in power management. Probably because of that head canon I didn't think about it again while working on the app.
Now I'm seeing signs that the app is failing when I replace WFE with WFI, and it may be because with WFI, it does in fact power down the SRAM bank including the stack.
It's hard to say for sure right now, because the app depends on calling WFE rather than WFI -- it fails with WFI, but in a different way, even when the powman code to turn off SRAM1 is #if-0'd out. To explain that in detail here would get deep into app-specific weeds, so suffice it to say: with WFI and the powman code turning off SRAM1, the app doesn't come up at all; with WFI but without the powman code, it comes up but fails at a later stage. With WFE (WFI never called at all), everything's fine, but possibly the powman stuff has no effect.
So this is a hypothesis, can't say that I've proved it for certain:
- The PICO_OK return from powman_set_state() doesn't mean that the power state has been changed now, but that it will be the next time WFI (not WFE) is invoked.
- If WFI is never called, then the power state transition never happens (WFE doesn't do the trick).
- If WFI is called, and a power state transition results in turning off SRAM1, then the app crashes after wakeup when stack memory accesses are attempted, if the stack is in SRAM1 as per default memory mappings.
Statistics: Posted by slimhazard — Tue Aug 27, 2024 1:03 am