search

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.48k stars 6.42k forks source link

STM32 Power Management Roadmap #19755

Open erwango opened 4 years ago

erwango commented 4 years ago

Umbrella ticket to track power management related activities. Aim is to STM32 related tickets/PR, but also cross-architectures tickets that might be relevant to enable power management use cases on STM32.

Strategy

There will be 2 mains tracks of power management on STM32 series depending on SoCs ability to handle low power use cases, roughly:

Current view

Should fix

[x] https://github.com/zephyrproject-rtos/zephyr/issues/14066

erwango commented 4 years ago

@FRASTM

r2r0 commented 4 years ago

@erwango Do you consider STM32WB55 as a member of L4 series or as a separate work for future?

erwango commented 4 years ago

@erwango Do you consider STM32WB55 as a member of L4 series or as a separate work for future?

@r2r0, STM32WB55 is not part of STM32L4, but HW is actually quite close so we'll quickly extend PM support to it.

gon1332 commented 4 years ago

@erwango @FRASTM

Since https://github.com/zephyrproject-rtos/zephyr/pull/18582 and https://github.com/zephyrproject-rtos/zephyr/pull/19881 are merged the progress should be updated.

FRASTM commented 4 years ago

In this issue, the low power modes of the stm32 soc series depend on the CONFIG_SYS_POWER_MANAGEMENT.

FRASTM commented 3 years ago

The low power control is being added to the drivers: uart_stm32_pm_control

FRASTM commented 3 years ago

When exiting the low power mode, the device is restoring its clock with stm32_clock_control_init in the pm_power_state_exit_post_ops function

FRASTM commented 3 years ago

Now supporting the low power modes (STOP0/1/2) on the stm32L5xx soc series (disco kit stm32l562e_dk board) using the LPTimer(#32999) : PR #33131

ycsin commented 2 years ago

@erwango @FRASTM would it be possible to list down STM32 PM related functions in the drivers that are yet to be implemented? i.e. peripheral WKUP from STOP? It is easier to identify areas that needs more work this way.

erwango commented 2 years ago

@erwango @FRASTM would it be possible to list down STM32 PM related functions in the drivers that are yet to be implemented? i.e. peripheral WKUP from STOP? It is easier to identify areas that needs more work this way.

Provided an update to wake up bullet

ycsin commented 2 years ago

@erwango Thanks, I also noticed that after enabling the ADC, the power consumption is increased by a little even when the application isn't sampling, I saw some ADC auto-sleep function when I go through the reference manual, I suppose that isn't supported yet?

erwango commented 2 years ago

@ycsin I don't think so. We're moving steadily but slowly on power mgmt, specially on peripherals. But as always, contributions are welcome.

ycsin commented 2 years ago

@ycsin I don't think so. We're moving steadily but slowly on power mgmt, specially on peripherals. But as always, contributions are welcome.

No worries, my application requires extremely low power and at some point I will have to start plugging all the leakages when most of the application's functionalities are implemented, if not I can't meet my requirements. Just figured that it would be more straightforward if we knew which area needs improvements

gordonklaus commented 2 years ago

My application also requires quite low power. It's great that Zephyr power management supports STOP modes on STM32. Now I need to start reducing peripheral power consumption. It took me awhile to figure out that e.g. UART, I2C, and SPI low power modes aren't yet implemented. @erwango Maybe you could add those as bullets to the list, for better visibility and to encourage their implementation? :)

Related issues: #37414 #37352 #43135

ycsin commented 2 years ago

Related issues: #37414 #37352 #43135

A few stm32 socs do support stop mode already. From my experience, I have no issue with i2c & adc while the mcu is in stop mode. For the uart, it requires quite a bit of work to be done, for now you will have to disable LPM whenever your application expects something on the RX line.

erwango commented 2 years ago

@gordonklaus Thanks for your interest

Maybe you could add those as bullets to the list, for better visibility and to encourage their implementation? :)

Sure, will do.

It took me awhile to figure out that e.g. UART, I2C, and SPI low power modes aren't yet implemented.

Would you mind illustrating your needs with concrete use cases ?

gordonklaus commented 2 years ago

When it comes to I2C, ADC, UART, and SPI, I think what remains to be done is to change to a low power pin configuration (e.g. analog input) and disable clock when the peripheral is not active.

gordonklaus commented 2 years ago

Would you mind illustrating your needs with concrete use cases ?

As I mentioned above (which I wrote before I saw your reply đŸ˜„) my need is for these peripherals to use less power when not active (or at least when the MCU is not active). Concretely, I need to get the whole system down around 10uA, which I can't do while those peripheral pins are connected.

matharman commented 2 years ago

Hi, I would also like to add that the peripheral clock for the STM32 entropy driver seems not to be restored when exiting from STOP modes. I think this would be fixed if the entropy driver better supported CONFIG_PM_DEVICE, as it could call clock_control_on when instructed to run PM_DEVICE_ACTION_RESUME or PM_DEVICE_ACTION_TURN_ON.

EDIT: I observed this on STM32L452, in case that difference in SOC series is relevant.

erwango commented 2 years ago

Hi, I would also like to add that the peripheral clock for the STM32 entropy driver seems not to be restored when exiting from STOP modes. I think this would be fixed if the entropy driver better supported CONFIG_PM_DEVICE, as it could call clock_control_on when instructed to run PM_DEVICE_ACTION_RESUME or PM_DEVICE_ACTION_TURN_ON.

EDIT: I observed this on STM32L452, in case that difference in SOC series is relevant.

Thanks for reporting. Would you mind checking https://github.com/zephyrproject-rtos/zephyr/pull/42375 ? It is not directly what you are describing, but closely related and I assume tested. If not solving your point (in a different fashion), please raise a dedicated issue). Thanks

louiscr commented 2 years ago

Recently uart peripheral power management support was added. In house we have our own suboptimal "fix" to disable this device. What's the roadmap for other peripherals like i2c and adc? This issue is actually one of my biggest complaints with zephyr on the STM32 and doesn't have a quick workaround solution.

erwango commented 2 years ago

Recently uart peripheral power management support was added. In house we have our own suboptimal "fix" to disable this device. What's the roadmap for other peripherals like i2c and adc? This issue is actually one of my biggest complaints with zephyr on the STM32 and doesn't have a quick workaround solution.

Since our bandwidth is limited, we need to prioritize features development. So far I2C and ADC PM awareness are not planned, thanks for reporting your need, we'll take it into account for next period.

zephyrbot commented 7 months ago

Hi @erwango, @FRASTM,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. Please confirm the issue is correctly assigned and re-assign it otherwise.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

Thanks!