Closed JojoS62 closed 3 years ago
Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers. Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2520
@0xc0170 I have created a simple test program to change the drive load level during runtime via stdin: https://github.com/JojoS62/Test-LSE/tree/master
setting the drive load level can be done in system_clock, but then a lot of files have to be touched. Maybe it can be placed in a more common SystemInit?
Hi
Ideal solution would be a new parameter in targets.json with a default value that could be override by each application?
A common place could be here: https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/lp_ticker.c#L171 ?
thanks for the feedback, yes, I will check lp_ticker, but there is also RTC thtat has an init for LSE and maybe others. Maybe RTC can use the lp_ticker init to have a common place for the LSE setting.
Another question is about the default value. I have checked some cube example code for H7, e.g. all are using high drive level for Nucleo boards. A high drive level is good for safe operation for these targets, but maybe bad for some custom hardware because it can reduce lifetime of the crystal. It is a hidden but important setting, that could be mentionend in the documentation, but who will read it?
it is not easy, a more common place would be mbed_sdk_init() in mbed_overides.c. There the SetSysClock() is called and LSE can be prepared before this call. Table 5 in the oscillator design guide shows that all newer devices have 4 levels and the HAL for these devices is unique, so it can be used in mbed_sdk_init() which is common for all targets. An exception is only F4_g2 with 2 levels and other HAL api calls, so only two cases are necessary. __HAL_RCC_LSEDRIVE_CONFIG() is used already in SetSysClock() for Wxx and L5 targets, but a prior call to HAL_PWR_EnableBkUpAccess() is missing, so it will have no effect. It is set to RCC_LSEDRIVE_LOW which is the default after reset, so this has no effect and can be removed. I'll try to prepare a PR, but it has to be checked carefully.
@0xc0170 Let's close this issue ? Thx
Description of defect
Activating the LSE clock may fail and throw an exception or LSE clock is not working or LSE clock is not stable with large jitter.
LSE clock is enabled for LPTimer (Mbed tickless and sleep mode wakeup), RTC clock and possibly other interfaces that can use the LSE clock.
The LSE clock typically uses a 32,768 kHz crystal and is automatically enabled on the first usage of LPTimer or RTC. There is a very large variety of crystals that can be used, a detailed description can be found in https://www.st.com/resource/en/application_note/cd00221665-oscillator-design-guide-for-stm8afals-stm32-mcus-and-mpus-stmicroelectronics.pdf For short, some devices use very tiny crystals with low load capcacitors to save (backup battery) power, some other use crystals with larger load capacitors for more stable clock. This difference requires different driver currents, the tiny crystals need low current and can be damaged by higher currents. The crystals with larger capacitors require a higher current to start and run stable. The default setting is the lowest driver load (DL) current, but this is not sufficient for many targets as they use crystals with higher capacities. The behaviour is random, LSE may work or produce no clock or clock with large jitter.
There is a setting necessary on targets that support adjusting the DL in the BDCR. There are HAL functions for this and in HAL examples, these are used already for some boards. https://github.com/ARMmbed/mbed-os/blob/eb382989de046fc80859bc8bcf899458cd36ed9a/targets/TARGET_STM/TARGET_STM32H7/STM32Cube_FW/STM32H7xx_HAL_Driver/stm32h7xx_hal_rcc.h#L7445-L7475
It must be decided where to add this setting, it must be executed before the LSE is enabled. LSE is in the backup power domain, so the LSE clock may be still active after a reset. In addition to the example code, it may be better to disable the LSE before changing the DL. Therefore, this setting can be placed also in system_clock.c, as it is more common than in lp_ticker or rtc_api.
Other issues that seems to be the same problem: https://github.com/ARMmbed/mbed-os/issues/13127 https://github.com/ARMmbed/mbed-os/issues/13411
Target(s) affected by this defect ?
STM32 with adjustable driver load for LSE, e.g. : F0 / F3 / F4_g2 / F7 / L0 / L4 / L4+ / L5 / G0 / G4 / H7 / WB / MP1
Toolchain(s) (name and version) displaying this defect ?
gcc-arm not depending on toolchain
What version of Mbed-os are you using (tag or sha) ?
mbed-os-6.3.0
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
mbed-cli
How is this defect reproduced ?
use RTC or LPTimer, enable MCO to monitor LSE frequency, e.g.
RCC_MCOx is target dependend.