search

STMicroelectronics / STM32CubeH7

STM32Cube MCU Full Package for the STM32H7 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
https://www.st.com/en/embedded-software/stm32cubeh7.html
Other
479 stars 298 forks source link

Wrong implementation of HAL_RCC_GetSysClockFreq, LL_RCC_CalcPLLClockFreq as well as SystemCoreClockUpdate in the examples #284

Closed cryptic-quasar closed 3 months ago

cryptic-quasar commented 4 months ago

Setup

Issue I encountered a problem setting the UART baud rate using LL_RCC_GetUSARTClockFreq(LL_RCC_USART16_CLKSOURCE) as the second argument of LL_USART_SetBaudRate. The data received on my PC using the USB-to-Serial adapter were bogus.

After spending hours, I finally spotted the issue and it turns out that the SystemCoreClock calculations in HAL and LL are wrong. The PLLM coefficient can only take values from 0 to 63 with 0 meaning division by 1, 1 meaning division by 2, 2 meaning division by 3, etc. The problem is that the methods I mentioned before do not take the increment of PLLM into account for the dynamic calculation of SystemCoreClock.

The following is taken from stm32h7xx_hal_rcc.c:

pllm = ((RCC->PLLCKSELR & RCC_PLLCKSELR_DIVM1) >> 4)  ;

where it must be:

pllm = ((RCC->PLLCKSELR & RCC_PLLCKSELR_DIVM1) >> 4) + 1;
TOUNSTM commented 4 months ago

Hello @cryptic-quasar,

Thank you for this report. As indicated in the RM0433 (section 8.7.11 page 398) see screenshot below the prescaler for PLLM can take values from 0 to 63 this is correct but the value 0 indicates that the prescaler is disabled. I don't see any need to add the +1 in the PLLM calculation. For the moment I didn't see the problem, may be I forgot some details. Could you please share with me more details about your issue.

With regards, Tasnim

Screenshot