Anyone had tried to set UART baudrate 921600 on STM32F4Discovery board?

bluenow1896 · ‎2016-12-11

Posted on December 11, 2016 at 21:22

I had created the project for

STM32F4Discovery

from STM32CubeMX,

and set the system to use external crystal of 8 MHz. I configured USART1 and USART2 to function as UART and repeatedly send strings out. The output looks all fine expect when configure the UART baudrate to 921600. When configure UART baudrate to 921600 on

STM32F4Discovery,

all received are 0x00 .

I

had tried the similar configuration on

STM32F

0

Discovery,

on which using HSI system clock. By my understanding, this will be less accurate than the HSE used on

STM32F4Discovery

board. But the UART1 and UART2 running on

baudrate

of

921600

is all fine.

I’m not so sure if I had made mistake on clock configuration. Please help.

Tesla DeLorean · ‎2016-12-11

Posted on December 11, 2016 at 23:15

Not sure I've done so recently, or with the HAL, but I had F2/F4 boards running in the low mega-bauds. Serial ports can handle quite high clock error numbers, so crystal vs RC doesn't make much of a difference, most error comes from the APB and the division thereof. The 921600 rate is below the ceiling for most RS232 level converters, so should be fine there.

If I were you, I'd review the USARTx->BRR wrt APBx clocks, and look at the signal on a scope (say of an 0x55 'U' character)

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

bluenow1896 · ‎2016-12-11

Posted on December 12, 2016 at 01:45

OK. I got the issue resolved.

By lower down the OverSampling = UART_OVERSAMPLING_8; instead of UART_OVERSAMPLING_16, which is provided by CubeMX, the UART 2 and UART 3 on STM32F4Discovery now run at baudrate of 921600 without problem.

bluenow1896 · ‎2016-12-11

Posted on December 12, 2016 at 01:10

looking in scope is the ultimate way to address this issue, but if the clock was drafting x%, it still be hard to determine where the problem comes from, the hardware of clock source or all the clock chain of configuration.

I had the latest HAL used in this case, this make me little harder to tracking down all the settings.

Thanks for your response.

Tesla DeLorean · ‎2016-12-11

Posted on December 12, 2016 at 01:41

Assuming usual clocking

baud_usart1 = 84000000 / USART1->BRR;

baud_usart2 = 42000000 / USART2->BRR;

I'd expect USART1->BRR to be 91, yielding an error of 0.16%

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

bluenow1896 · ‎2016-12-12

Posted on December 12, 2016 at 17:32

Even I had the problem resolved at this moment, it is still be interested to find out what happens under hood.

As on STM32F0Discovery board, on which using HSI clock, easily support UART baudrate at 921600, with OverSampling = UART_OVERSAMPLING_16, which is provided by CubeMX; But on STM32F4Discovery board, on which using HSE clock, I have to reduce OverSampling = UART_OVERSAMPLING_8 to make it run properly for UART baudrate of 921600.

I will investigate into the low layer/register settings once time permit.

Tesla DeLorean · ‎2016-12-12

Posted on December 12, 2016 at 18:35

There have been complaints about the math for computing the baud rate divider, ST seems to uses a very complicated method that seems to belie the simplicity of the hardware.

For 16x mode the APB clock driving the USART is going to be up near 16 MHz to deliver 921600, and significantly higher to get the granularity fine enough if you aren't using magic value crystals.

https://community.st.com/0D50X00009XkdioSAB

https://community.st.com/0D50X00009XkflwSAB

https://community.st.com/0D50X00009Xkf9ESAR

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..