Closed BatuuKurt closed 5 years ago
Hi Kurt,
Thank you for pointing out this issue. Actually, we found it out too and fixed it in release v1.11.0. Currently, release v1.11.2 is available on GitHub.
The code snippet below shows how the fix has been implemented (almost the same way as you did): https://github.com/STMicroelectronics/STM32CubeL0/blob/65f3157a89766c2f89442115c49d29df73485eb9/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_ll_rcc.c#L590-L599
Could it be possible that you are using a firmware release prior to v1.11.0? Please let us know if it is the case and thank you once more for your contribution.
With regards,
ST Internal Reference: 32221
Ali, thanks for the hint. An update to v1.11.2 fixed the issue.
Hi Kurt,
Really glad to hear that.
Describe the set-up
Describe the bug When HSI with the HSI16DIV enabled is used as system clock, the function RCC_GetSystemClockFreq() returns the wrong frequency, because it only returns the define HSI_VALUE. Because of this at least the LPUART baud is calculated wrong.
How To Reproduce Setup HSI as system clock and enable the HSI16DIV Flag in the RCC->CR.
Additional context In stm32l0xx_ll_rcc.c it should be:
case LL_RCC_SYS_CLKSOURCE_STATUS_HSI: /* HSI used as system clock source *'
{
if ((RCC->CR & RCC_CR_HSIDIVF) != 0)
{
sysclockfreq = (HSI_VALUE >> 2);
}
else
{
sysclockfreq = HSI_VALUE;
}
break;
The wrong behaviour seems to be in every RCC__GetFreq() function in the stm32l0xx_ll_rcc.c
It is correctly implemented in the stm32l0xx_hal_rcc.c
Screenshots If applicable, add screenshots to help explain your problem.