Needs rebase ;)

rebased (but waiting for #11173 and #stm32f7).

Maybe this one can be merged directly without waiting for the 2 other PRs. What do you think @vincent-d ?

maybe the SRAM2 thing could be made configurable.

Done here: 94562f7#diff-44501824d2f98f5e4d5ee081b01fd4f0R77

Hope this is ok for you.

@aabadie feel free to merge

@aabadie feel free to merge

Thanks @vincent-d ! I'd like to have a last round of testing. Maybe @fjmolinas can find some time to give this a last try. Otherwise, it won't be before next week.

@aabadie do you want a round of testing on all boards, I only have f4, l0, l1, l4. But not f3 with is the subject of the PR.

PROBLEMS FOUND:

L0:

• Master: when reseting after STANDBY STOPMODE consumes 3uA
• This Branch: when reseting after STANDBY STOPMODE consumes 30uA

L1:

• Master: STANDBY consumes 3uA
• This Branch consume on STANDBY 0.9 mA

F4 and L4 present no problem

PROBLEMS FOUND

Thanks for testing @fjmolinas. I see nothing in the code changes of this PR that could explain such a difference, implementations for L0 and L1 are the same. Is your local master up-to-date with upstream ? (I'm wondering if another STM32 pm related PR could have introduced it, like #9521 for example)

@aabadie you are right, I was working with an old master branch. Problems where introduced in #9521. To fix when seting PM_STOP_CONFIG for L0 and L1 do:

#define PM_STOP_CONFIG (PWR_CR_LPSDSR | PWR_CR_ULP | PWR_CR_CWUF)

WUF must be cleared before entering stop mode, and it is cleared by writing PWR_CR_CWUF. It wasn't that explicit in the datasheet since it said that WUF must be 0 but didn't explicitly talk about CWUF.

Maybe add a comment before the configs definition, it should be clear what every flag is doing.

Thanks for testing and providing the fix @fjmolinas ! I pushed one last commit with it. If the comment is fine for you, I guess we can go with this one.

@aabadie yep! go!