STM32WL ADC doesn't work with power management

[honestech74]

Describe the bug If enabled CONFIG_ADC and CONFIG_PM, you can read just once using adc_read(), then Zephyr halts.

To Reproduce Steps to reproduce the behavior:

1. add the nucleo_wl55jc.overlay to samples/drivers/adc/boards

   
   / {
   zephyr,user {
       io-channels = <&adc1 11>;
   };
   };

&adc1 { pinctrl-0 = <&adc_in11_pa15>; status = "okay"; };

2. add configs to the sample project

CONFIG_PM=y

3. build and flash with `nucleo_wl55jc` board
4. see the log

**Expected behavior**
It should show the ADC reading every second.

**Logs and console output**
Before enabled CONFIG_PM, could see the ADC value every second.
After enabled CONFIG_PM, only could see the ADC value one time, then not running.

**Environment (please complete the following information):**
 - Ubuntu 18.04
 - Toolchain: 0.12.4
 - Zephyr v2.6.99

[UPDATED]
 - Zephyr commit SHA-1:  [`57690f5`](https://github.com/zephyrproject-rtos/zephyr/commit/57690f566e806c4f3cb956ce3594b6907e229fb4)

[FRASTM]

There is only a AN5568 . Could the situation apply in this sample ? "The STM32WL devices embed a multiple 12-bit/2.50 Msps ADC. This very fast and accurate converter can jeopardize the battery lifetime if left powered-up. As the ADC consumption is roughly proportional to the acquisition frequency (around 200 μA/Msps), from a consumption standpoint, the application can choose between the following solutions: – Perform the acquisition at low speed to limit the maximum current. – Perform the acquisition at the maximum speed to switch back to ultra-low-power mode quickly. When the acquisition is performed slowly, the ADC consumption itself can go down to few tens of a μA, drastically limiting the maximum current. This may be mandatory when the power source provides a limited current. If the CPU has no other task to perform during that time, this slow acquisition increases the time spent by the system in Run, Sleep, LPRun or LPSleep mode, versus the time spent in Stop or Standby ultra-low-power mode."

Otherwise, even if the stm32wl is close to the stm32wb serie, the sequence to switch to HSI before entering Stop Mode is not mentioned for the stm32wlx. When testing, the samples/drivers/adc on nucleo_wb55rg with CONFIG_PM is correct.

[ABOSTM]

Zephyr v2.6.99 doesn't exist. Do you mean 1.6.99 ? I tested on my side and it is working well: board: nucleo_wl55jc sha1 : 17d2e9d084b2f02f8d39cd38eecdd7c0b5af59a2 I follow your To Reproduce steps

[FRASTM]

@honestech74 Can you confirm that you have the power.c for the ./soc/arm/st_stm32/stm32wl --> the PR #36574 has introduced the power management for the stm32wl soc serie.

[honestech74]

Zephyr v2.6.99 doesn't exist. Do you mean 1.6.99 ?

@ABOSTM Sorry for the confusing version. I am in master branch and you can check the version from this file. https://github.com/zephyrproject-rtos/zephyr/blob/main/VERSION#L1-L5 Also commit SHA1: 57690f5

Can you confirm that you have the power.c for the ./soc/arm/st_stm32/stm32wl

@FRASTM Sure, I have it and it works well for boards/stm32/power_mgmt/blinky

[honestech74]

Zephyr v2.6.99 doesn't exist. Do you mean 1.6.99 ? I tested on my side and it is working well: board: nucleo_wl55jc sha1 : 17d2e9d I follow your To Reproduce steps

@ABOSTM I have double checked on your commit sha, but couldn't get running. If you followed Reproduce and got running, please check your SHA. I guess you are in another branch or miss CONFIG_PM? I have another issue on I2C with CONFIG_PM.

[EDIT] it's my git HEAD for checking.

$ git rev-parse --short HEAD
17d2e9d084

[ABOSTM]

@honestech74 , Let me change a bit the status of my tests: After flashing the board (west flash with openOCD), it is working fine, even after pressing reset button, it works But if I unplug and replug the board (ST-link usb powered), then it fails, ADC reading: xxx Displayed only once in console.

[honestech74]

@ABOSTM You are right, I can see it's running when flash using stm32cubeprogrammer with openocd, but stopped after unplug and replug. Even if it's running, getting 1.2mA power consumption and there are high peaks every a second(there is k_msleep(1000) in sample) Is it reasonable? I guess it might be about a few hundreds of uA in average.

I'd like to use J-Link so tested with it until now. It's stopped after show one ADC log. I never saw this difference between programmers, I can't trust the result when using stm32cubeprogrammer.

[honestech74]

@ABOSTM Can you test it using J-Link? It seems like there is something wrong in ADC driver. I've tested ADC without CONFIG_PM but stopped SoC using LL library and init the clock after wake up. But it's not running after wake up.

[honestech74]

I could get ADC running with STOP0/1/2 mode with HAL library. I could stop SoC using LLPWR* functions and wake up the counter(RTC). But there are some operations to make it working. Before entering STOP mode, I have disabled ADC. When wake up, enabled ADC. I am not sure whether ther is any specification on ST datasheet and reference manual.

[FRASTM]

It is mentioned that the content of the ADC registers is retained in STOP0/1 but not in STOP 2, so to be re-initialised.

[FRASTM]

This seems specific to stm32wl55jc low power STOP2 mode, probably because "The content of all other peripherals is reset and must be reprogrammed." Trying ./boards/arm/nucleo_wl55jc/nucleo_wl55jc.dts

&cpu0 {
    cpu-power-states = <&stop0 &stop1>;
};

the "ADC reading" continues after cold reboot

[honestech74]

@FRASTM Thank you for your work. I have understood that ADC registers are not retained in STOP2 mode and got working by using HAL instead of Zephyr PM. If I stick to using Zephyr PM, can we have some callbacks for it? E.g. if we can register the callbacks for PM (maybe in power.c), users can register their custom code for ADC and other peripheral for STOP2 mode, and PM will call the callbacks before suspending and after wake up etc. So user can handle all peripherals without any issue with CONFIG_PM and pure Zephyr style. I am not sure if Zephyr PM has such specifications.

[FRASTM]

Yes, more or less, for each peripheral, entering/exiting STOP2 mode. I guess this is the purpose of the pm_device Pointer to the device's power management resources, which appears in the DEVICE_DEFINE like PM_DEVICE_DT_DEFINE(SPI(idx), gpio_stm32_pm_action);

[nobodywasishere]

I believe I am also running into this issue with the LoRa E5 Dev Board (STM32WLE5JC), where it will just halt during adc_read() and fails to print anything (including ADC Reading:). Is this related to this issue?

[erwango]

@nobodywasishere Do you enable PM ?

[nobodywasishere]

@erwango PM is not enabled, no

[erwango]

@erwango PM is not enabled, no

So likely it is another issue. Please raise a dedicated ticket giving any information that would help.

[sense-Jo]

I occurred the same issue that the ADC on STM32WL does not work after STOP2 sleep. But I could solve it by re-initializing the ADC before it is used again, with the help of Device Runtime Power Management. However, I'm not sure whether this is the proper way to do it, and I didn't test it intensively either. Nevertheless, one might want to have a look at this branch of my fork.

[zephyrbot]

Hi @erwango,

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.

@honestech74 you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!

[Martdur]

The issues seems to still be present on STM32WL series. I managed to solve the issue based on what @sense-Jo has done. Changes are minor since the file adc_II_stm32.c evolved:

• Adding /* enable device runtime power management */ err = pm_device_runtime_enable(dev); if ((err < 0) && (err != -ENOSYS)) { return err; } at the end of static int adc_stm32_calibrate(const struct device *dev) in adc_stm32_pm_action.

• Adding error = pm_device_runtime_get(dev); if (error < 0) { return error; } in adc_stm32_read

• Adding pm_device_runtime_put(dev); at the end of adc_stm32_isr(const struct device *dev)

What do you think about the changes ? Can it be interesting to make a PR ?

[erwango]

@Djammall Sure, go ahead, please make a PR. @gautierg-st will be able to provide guiding during the review