STM32L4 - Update deepsleep implementation

[svastm]

Description

During deepsleep enter, the STM32L4 devices were entering in stop mode 0 instead of stop mode 1 due to a PWR clock not initialized.

Status

READY

Migrations

NO

Steps to test or reproduce

#include "mbed.h"

int main() {
    printf("before deepsleep\n");
    deepsleep();
    printf("after deepsleep\n");
}

Flash this code on a STM32L4 and check the power consumption on IDD jumper. It should decrease from 110 uA to 9 uA with this PR

[sg-]

/morph test

[sg-]

@mbed-bot: TEST

HOST_OSES=ALL
BUILD_TOOLCHAINS=ALL
TARGETS=ALL

[sg-]

please update to follow code style guidelines https://docs.mbed.com/docs/getting-started-mbed-os/en/latest/Full_Guide/Code_Style/

[helmut64]

There is also a deepsleep wakeup delay problem, I believe it needs 0.3 secs instead of 10 usecs. Using the regular sleep there is no wakeup delay. Maybe this is related to this problem. Regards Helmut

[mbed-bot]

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 913

Test Prep failed!

[svastm]

I rebase to correct the code style. It might have broken the morph test ?

[svastm]

There is also a deepsleep wakeup delay problem, I believe it needs 0.3 secs instead of 10 usecs. Using the regular sleep there is no wakeup delay. Maybe this is related to this problem. Regards Helmut

Hello @helmut64, with the low power timer coming in this PR #2764 I measure on an oscilloscope 1.00116s for a 1 sec delay. Can you provide the code you use to detect 300ms of delay ?

[mbed-bot]

[Build 957]
SUCCESS: Building succeeded and tests were run! Be sure to check the test results

[bridadan]

@svastm That's correct, the bot couldn't find the commit any more. I will restart the test.

/morph test

[helmut64]

@svastm here is simple test program which works on the Nucleo64-STM32L4, you can see that the LED has a significant delay after clicking on the bottom:
https://developer.mbed.org/users/Helmut64/code/Nucleo_blink_led_deepsleep/
I measured this some time ago with a logic analyser in my solution.

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 925

All builds and test passed!

[0xc0170]

please don't introduce spaces on empty lines

[svastm]

Yes fixed

[svastm]

Hello @helmut64, I tried your code and I found a 200ms delay on wake up. This is because the board try to use HSE clock on startup/wakeup and there isn't one connected to the pins. You can try to use MCO one by moving solder bridges. (6.7.1 in board user manual).
or set USE_PLL_HSE_EXTC in system_stm32l4xx.c to 0 and use only MSI/HSI.

[helmut64]

@svastm regarding the wakeup delay, I belive you are talking about the MB50 which is open in the L4 case. The MCO clock is not an option because in a standalone operation with my board there is no STLink, however I like to use the out of the box mbed binary for developing my complete solution. Anything we can do within mbed to instruct the HAL to avoid this 200ms timeout.
Thank you Helmut.

[svastm]

@helmut64 Thanks for reporting, I see the point. Can you please open an issue where you describe the problem and the behavior you expect. It will avoid to lost the report with this merged pull request.