Allow to use all STM32 targets prescaler for LPTIM

[hallard]

Summary of changes

Allows using all prescalers available for STM32 LPTIM , allowing to have less consumption on long sleep such as LoRaWAN app

Impact of changes

Power consumption optimization

Migration actions required

Documentation

Power consumption graph below, measured just after LoRaWAN join at the begining

Setting to today maximum value to 4 show power peaks in red and average consumption (3m46s runtime) to 5.57uA

"target.lpticker_lptim_clock": 4,
"target.lpticker_lptim": 1,
"events.use-lowpower-timer-ticker": true,

This PR allows prescaler up to 128 resulting power peaks in green and average consumption (3m46s runtime) to 4.16uA

"target.lpticker_lptim_clock": 128,
"target.lpticker_lptim": 1,
"events.use-lowpower-timer-ticker": true,

Leaving default values to 1 provide following graph, power peaks in yellow and average consumption (3m46s runtime) to 9.85uA

"target.lpticker_lptim_clock": 1,

What's interesting is that longer is sleeping higher is consumption on wake up, my assumption is that mbed-os has more things to do so takes more time when waked less often, makes sense, confirmed by zooming peaks

---

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

@0xc0170 , @jeromecoutant , @MarceloSalazar

---

[ciarmcom]

@hallard, thank you for your changes.
@jeromecoutant @0xc0170 @MarceloSalazar @ARMmbed/mbed-os-maintainers please review.

[LMESTM]

@hallard please note that such change will reduce the LP timer resolution and will have impacts on mbed-os timer precision and therefore on scheduling. The precision will be 128 timers lower with pre-scaler set to 128 vs. 1.

mbed-os mandates that frequency is between 8KHz and 64KHz.
https://os.mbed.com/docs/mbed-os/v6.14/porting/low-power-ticker.html
I think this will not be the case with such setting. Nevertheless if this is acceptable for a given application, I'm ok with it, but clear documentation and "disclaimers" are needed.

[jeromecoutant]

Agree with Laurent, we can approve if there is some "comments" that choosing value greater than 4 can work, but out of mbed-os requirements.

[hallard]

I think this will not be the case with such setting. Nevertheless if this is acceptable for a given application, I'm ok with it, but clear documentation and "disclaimers" are needed.

Sure, of course, do you want me to update the documentation also or leaving targets.json unchanged so this one is not mentioned anywhere?

[ciarmcom]

This pull request has automatically been marked as stale because it has had no recent activity. @0xc0170, @MarceloSalazar, @ARMmbed/mbed-os-maintainers, please complete review of the changes to move the PR forward. Thank you for your contributions.

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