STM32L5: corrected voltage scaling when using MSI

[chrJost]

Summary of changes

Up to now the voltage scaling of the STM32L5 is set before the clock to the peripheral module is enabled. Therefore the voltage scaling is not applied correctly, the STM32L5 devices seem to always run in default mode.
I corrected this by moving the code lines around, and could confirm in custom STM32L552ZE hardware that the voltage scaling now works.

I am not aware if there are any tests yet that could catch this change of behaviour. If somebody with more knowledge of the test system could comment on this, I would be grateful.

Impact of changes

Migration actions required

Documentation

---

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

---

[ciarmcom]

@chrJost, thank you for your changes.
@ARMmbed/mbed-os-maintainers please review.

[jeromecoutant]

Good catch!
Every HAL_PWRxxx calls should be preceded by __HAL_RCC_PWR_CLK_ENABLE()

[chrJost]

@jeromecoutant do you happen to know if any tests would check for the speed of the chip, so that this kind of error could be caught? I did a short check in the STM32L452xx folders, the init sequence there looks very different, so this kind of error could be in any other (STM32?) device as well. It would be very tedious to check everything by hand.

Another thought I had was, if this kind of error could also happen in the init of other peripherals. I guess this leads back to the question if it can be detected automatically...

[mbed-ci]

Jenkins CI Test : ✔️ SUCCESS

Build Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs	Status
jenkins-ci/mbed-os-ci_unittests	✔️
jenkins-ci/mbed-os-ci_cmake-example-ARM	✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM	✔️
jenkins-ci/mbed-os-ci_cmake-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_cmake-cloud-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_greentea-test	✔️

[0xc0170]

@jeromecoutant do you happen to know if any tests would check for the speed of the chip, so that this kind of error could be caught? I did a short check in the STM32L452xx folders, the init sequence there looks very different, so this kind of error could be in any other (STM32?) device as well. It would be very tedious to check everything by hand.

I'll merge this but the question above remains.

[chrJost]

I'll merge this but the question above remains.

I will open an issue for this, since this question is probably out of scope for this PR.

[jeromecoutant]

It is maybe also out of scope of mbed :-)
Anyway I have requested some tip from ST driver team

[chrJost]

That is why I would use an issue for that, since that can easily be rejected as out of scope :)