My use case: when A7 goes to VLLS, switch M4 to VLLS and wait for an event (GPIO or LPTMR) to wake up, then wake up A7 too.
Platform: 7ULP EVK
7ULP: any default image (using core-image-base)
M4 SDK: SDK_2.7.0_EVK-MCIMX7ULP
From the power_mode_switch example, I have simplified the task PowerModeSwitchTask() to switch the M4 to VLLS power state as soon as the A7 is itself in VLLS mode. However, in this situation, the M4 goes into VLLS prior to seeing the message "CA7 in VLLS status, power off unused regulator!", which means before the peer core is in 'deactivating' state.
As a result, the wake up never happens, whatever the selected mode to trigger it (GPIO/VOL+ or LPTMR). The only workaround being to add a 1 second delay after the CA7 is detected to be in VLLS state. This timing issue should have another robust option to solve it, do you know how?
And by the way, is there a potential issue in the example within the state machine of the APP_SRTM_PollSuspend() function?
I attached the two modified files from the power_mode_switch project for simple testing.
CA7 can be switched to VLLS with:
# echo "mem" > /sys/power/state
By default, GPIO event is selected (see TODO tag) and the extra delay workaround has been commented out (see FIXME tag).
In the SDK "APP_SRTM_LfclEventHandler" is the subscribed service by SRTM. So, it will start the timer, once there is suspend request and this timer eventually will call "APP_SRTM_PollSuspend". So, as suggested by Wayne Feng , after "CA7 in VLLS status, power off unused regulator!" print you should take the further decision of your application use case. I would suggest to remove the polling of A7 power mode in PowerModeSwitchTask() and rely on "APP_SRTM_PollSuspend". I hope this way you no need to tweak on timing delay of 1 second.
When relying on the CA7 peer core state (basically by checking SRTM_PeerCore_State_Deactivated or SRTM_PeerCore_State_Activated), updated in "APP_SRTM_PollSuspend()", that is much more reliable without any arbitrary delay.
I guess there should be a smarter way to do it. And it would definitely be nice to have it already implemented in the original example to have it more robust than it is now. Currently, it works thanks to delay brought by the prints and the user input.
It's obviously wrong to make M4 enter VLLS before seeing the message "CA7 in VLLS status, power off unused regulator!".
In mulitple tasks environment, you need to ensure the sequence between tasks.
Indeed, we need to pay attention to the sequence between tasks. But that is a generic answer.
Please keep in mind that my example is very close from the original power_mode_switch example. The sequence between tasks is not considered neither in the original project. What makes it work is only the need for a user selection (which adds a delay). Force the user selection as I did and this issue will occur.