zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.33k stars 6.33k forks source link

Low power mode for STM32F4 chips #60558

Closed niedzwiecki-dawid closed 9 months ago

niedzwiecki-dawid commented 1 year ago

Is this request related to a missing driver support for a particular hardware platform, SoC or board? Please describe. There are no low power states implemented for the any STM32F chip.

Describe why you are asking for this support? I need to be able to save as much power as possible in my project with the STM32F412 chip. It looks like low power state should help a lot.

Additional context My main concern is that all 1.2V domain clocks are off in the Stop mode. The only working programmable wake-up source is RTC. I guess that means SYSTICK is not increased during the low power mode.

Have anybody considered implementing the low power mode for STM32FX family and how to overcome the described problem?

erwango commented 1 year ago

My main concern is that all 1.2V domain clocks are off in the Stop mode. The only working programmable wake-up source is RTC. I guess that means SYSTICK is not increased during the low power mode.

Indeed SYSTICK can't be used to count ticks in stop modes so, as per current kernel behavior, an alternate tick source (device implementing timer API) should be used. Only available peripheral would indeed be RTC.

Some works around this: https://github.com/zephyrproject-rtos/zephyr/issues/14066 (pretty old but may contain usefull pieces). https://github.com/zephyrproject-rtos/zephyr/pull/32758 (on L1, but I hope the RTC implementation should be close to what you would need).

niedzwiecki-dawid commented 1 year ago

Thanks a lot for the comment. I can see from the roadmap that implementing support for F4 series is on your table. Have you started the implementation yet?

If not, have you decided how to handle it?

erwango commented 1 year ago

Thanks a lot for the comment. I can see from the roadmap that implementing support for F4 series is on your table. Have you started the implementation yet?

If not, have you decided how to handle it?

Well actually, this was listed as a separate point to make it clear this is something a part from the main line PM handling on STM32. Enabling PM on FX devices is actually quite low prio in our tasks list and hence I don't see us working on it on a foreseeable future.

niedzwiecki-dawid commented 1 year ago

Ok, good to know.

I understand that you are not going to implement it soon, but have you decided what it should look like? At the moment, I see two options which I haven't tested I may be stupid:

  1. Add RTC timer driver(sys_clock API) and mark it as a dependency for enabling PM for Fx series.
  2. Keep using Cortex-m systick and increase the Systick counter after wake-up based on the RTC timer. Also use the RTC alarm to wake up the device if needed. This option looks like hard, not sure if even possible, to implement.
erwango commented 1 year ago

Not stupid at all.

  1. Is the default zephyr way to go today, but using RTC as the single tick source is really not easy, specially if you want a fine grained tick rate. So you'd have to make compromises to have a reliable tick count.
  2. Is not supported as I'm aware of today, it may require some thinking and discussion with kernel in order to make it work correctly, but it should not be that complex, and it would be much easier to handle and reliable than 1. Besides, it could be reused even on other series which would like to use sleep states where LPTIM is not powered, such as Standby states.
niedzwiecki-dawid commented 1 year ago

Thanks a lot for the comments. I'm going to start development soon and probably try to implement both solutions.

erwango commented 9 months ago

@niedzwiecki-dawid Following merge of #61631, do you plan to upstream a sample to demonstrate it ? Would be nice to have this. Minimum benefit would be to ensure code is build in CI. But also ensure non regression testing (for instance in case of counter API update)

niedzwiecki-dawid commented 9 months ago

Sure, I'm going to send PR with power management support for STM32Fx chips with tests. Please give me a few days.

Anyway, I have a question. I can see that non of the STM32 chips add Sleep mode. However, some of the chips add Stop0/Stop1, but it is clearly listed in the RM. I've seen that STM32F4x chips don't have Stop0/Stop1 division. However,t there are some additional configs that can be set before entering the Stop mode e.g. for the STM32F412 image

According to HAL, most of them are optional. Only Low-power Voltage regulator on during Stop mode(LPDS bit) is supported by all STM32F4 chips. Should these two be added as suspend-to-idle and different sub-states? Is there any approach for such cases?

erwango commented 9 months ago

Sure, I'm going to send PR with power management support for STM32Fx chips with tests. Please give me a few days.

Great! I'm having issues to get it work.

According to HAL, most of them are optional. Only Low-power Voltage regulator on during Stop mode(LPDS bit) is supported by all STM32F4 chips. Should these two be added as suspend-to-idle and different sub-states? Is there any approach for such cases?

There is no requirement on that. You can add support for all of them or only the ones that are meaningful to you application. My only request would be to add a matching sample/test code. One suggestion could be to support 2 or 3 modes which could map to stop0/1/2 from functional point of view.

erwango commented 9 months ago

Great! I'm having issues to get it work.

Finally got it working. I was facing an issue with Back Up Access. We really need a framework to deal with this.

niedzwiecki-dawid commented 9 months ago

Back Up Access TBH not really sure what it is.

https://github.com/niedzwiecki-dawid/zephyr/tree/f4_lpm here are some WIP changes if you need to compare some code.

erwango commented 9 months ago

Back Up Access TBH not really sure what it is.

On some devices, you need LL_PWR_EnableBkUpAccess(); in RTC driver. But LL_PWR_DisableBkUpAccess() is called at various places.

niedzwiecki-dawid commented 9 months ago

STM32F4 Power management added with #63187 and #65050 and some smaller PRs.