STM32: LSE DRIVE feature update

[jeromecoutant]

Summary of changes

Hi

Got few regression after #13797 integration
(for example with hal-tests-tests-mbed_hal-rtc_reset)

I think we should never switch off LSE during target life (used for LPTICKER, RTC, ...)
Now the correct LSE DRIVE value is set once before starting LSE.

There was also an issue with the macro name in targets.json file

@JojoS62

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]

@jeromecoutant, thank you for your changes.
@ARMmbed/team-st-mcd @ARMmbed/mbed-os-maintainers please review.

[JojoS62]

thanks for fixing the macro name.

I have turned off LSE before changing the LSE drive setting, this is not possible when LSE is already running. It remains also running after an reset, the device needed a power down cycle to accept changing the register.
Maybe it is a better solution to skip changing the settings when LSE is already running, this should be possible by existing macros. Putting this code in mbed_overrides was the earliest stage I found where the LSE should not be enabled.

[jeromecoutant]

When you plug the target, LSE is OFF, so LSE drive is applied.
Then, configuration is never lost

[JojoS62]

but what happens when you press the reset button or use restart in the debugger? My experience was thas setting the LSE drive level failed in this case.

[jeromecoutant]

but what happens when you press the reset button or use restart in the debugger? My experience was thas setting the LSE drive level failed in this case.

No, LSE drive will not be updated with reset button or with the debugger.
This will work at target power on, or if local application swith off LSE before reset.

[0xc0170]

CI started

[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-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_cmake-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM	✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-cloud-example-ARM	✔️
jenkins-ci/mbed-os-ci_cmake-example-test	✔️
jenkins-ci/mbed-os-ci_dynamic-memory-usage	✔️
jenkins-ci/mbed-os-ci_greentea-test	✔️
jenkins-ci/mbed-os-ci_cloud-client-pytest	✔️

[0xc0170]

@jeromecoutant I fixed the PR type and tests , do not forget to fill in the template