Bug Report: LL USART->BRR register configured incorrectly in LL_USART_Init in stm32l4xx_ll_usart.c

[Reuben Hill]

Posted on October 25, 2017 at 16:10

I have an STM32L4 project configured to use LL drivers in CubeMX. I am using

• An stm32L4 series MCU
• USART1
• Desired baud rate 115200

The LL library function

LL_USART_Init(USART1, &USART_InitStruct);

does not correctly set the LL_USART_InitTypeDef USART_InitStruct

USART_InitStruct.BaudRate  parameter for USART1.

In the source stm32l4xx_ll_usart.c this appears to be due to line 288

ErrorStatus LL_USART_Init(USART_TypeDef *USARTx, LL_USART_InitTypeDef *USART_InitStruct)

{

  ...

  periphclk = LL_RCC_GetUSARTClockFreq(LL_RCC_USART1_CLKSOURCE);

  ...

}

returning 40 MHz instead of 80 MHz (as set in CubeMX), causing the `USART->BRR` register to be set to half the value it should be as described in reference manual RM0394. The effective baud rate is then twice that requested by the USART_InitStruct.

The line causing the problem appears to be 352 in stm32l4xx_ll_rcc.c

uint32_t LL_RCC_GetUSARTClockFreq(uint32_t USARTxSource)

{

  ...

  usart_frequency = RCC_GetPCLK2ClockFreq(RCC_GetHCLKClockFreq(RCC_GetSystemClockFreq()));

  ...

  return usart_frequency;

}

Given that this occurs in the LL drivers I must assume this is an LL driver bug and not a CubeMX one. Note that the LL driver is reporting the peripheral clock to be half the value needed for communication to work correctly. When configured with HAL, the baud rate is set correctly.

Since this appears to be the only place to report such bugs, I am posting this here. Please reply if more information is required.

EDIT: Incorrect line number quoted in 

stm32l4xx_ll_rcc.c updated.

#stm32l4 #bug #ll-bug #ll-drivers #bug-report

[Tesla DeLorean]

Posted on October 25, 2017 at 17:26

Isn't USART1 on APB2? Would be code below that at issue.

I'd expect APB2 to be 80 MHz in normal DIV1 cases, perhaps you want manually decode the RCC settings, and confirm HSE_VALUE, or clock speeds provided as inputs.

[Reuben Hill]

Posted on October 25, 2017 at 18:10

My apologies, I quoted the wrong line number in stm32l4xx_ll_rcc.c: I meant to refer to line 352, which is the one that my STLINK debugger says is being run. It's the default case in the switch statement

uint32_t LL_RCC_GetUSARTClockFreq(uint32_t USARTxSource)

{

  ... 

  if (USARTxSource == LL_RCC_USART1_CLKSOURCE)

  {

  /* USART1CLK clock frequency */

  switch (LL_RCC_GetUSARTClockSource(USARTxSource))

  {

    ...

    default:

      usart_frequency = RCC_GetPCLK2ClockFreq(RCC_GetHCLKClockFreq(RCC_GetSystemClockFreq()));

      break;

  }

}

I'll update my original post to reflect the line number.

[Tesla DeLorean]

Posted on October 25, 2017 at 19:10

I think you miss my point, which is why 

RCC_GetPCLK2ClockFreq() would return 40 MHz

You'd want to review the math that gets you that answer. Or if that line is entirely obtuse.