AnsweredAssumed Answered

STM32F4 Std Periph Lib USART baud rate BRR bug?

Question asked by De.Avik on Mar 14, 2017
Latest reply on Mar 15, 2017 by De.Avik

I've been starting to use an F446, and while the clock settings look OK (at least PWM frequencies match expected, but I can definitely test this more), I consistently get half the requested baud rate on USART3. Looking into the code, in USART_Init in the standard peripheral library,


/* Determine the integer part */
if ((USARTx->CR1 & USART_CR1_OVER8) != 0)
{
/* Integer part computing in case Oversampling mode is 8 Samples */
integerdivider = ((25 * apbclock) / (2 * (USART_InitStruct->USART_BaudRate)));
}
else /* if ((USARTx->CR1 & USART_CR1_OVER8) == 0) */
{
/* Integer part computing in case Oversampling mode is 16 Samples */
integerdivider = ((25 * apbclock) / (4 * (USART_InitStruct->USART_BaudRate)));
}
tmpreg = (integerdivider / 100) << 4;

 

i.e. the "integer part" of the baud rate divider is = 25 * apbclock / ((2 * (2-OVER8) * BR * 100) = apbclock/(16 * (2-OVER8) * BR)

 

However, looking at the RM (both for F446, F405, and probably other F4 chips), e.g. in 25.4.4 in the F446 RM, 

Tx/Rx baud = apbclock / (8 * (2 - OVER8) * divider

 

Considering an example where I only need an integer divider, it seems like the SPL code is a factor of two off, right? Am I missing something?

 

EDIT: This is with the latest v1.8.0 of the STM32F4xx_StdPeriph_Driver

Outcomes