2021-09-20 08:41 AM
Hi!
I am operating on an STM32F446 chip and I have the following issue:
I tested out a communication system where I attached a 912600 baud communication with another device via UART1 on a STM32f446 NUCLEO Board. All worked out well, no errors or other issues.
Now we have designed a pcb with the stm32f446 chip, and is still running on 912600 baud via UART1. The issue is, now we have a communication-loss, after startup, no bytes can actually be read anymore in our serial port on UART1. I tried out 115200 Baud instead of 912600 and it fixes the problem. But I can not figure out why exactly. We have no oscillator attached on OSC32_IN and OSC32_OUT , only on OSC_IN and OSC_OUT we use an extern 20MHz crystal oscillator.
I read the reference manual of the stm32f446 but I can't really understand what's meant by oversampling on page 810 - 816 and all the rest is also pretty hard to understand for me..
Has the OSC32 a big impact on using a high baud rate like 912600 on UART1, or could I have missed something else in the transformation from nucleo board to the custom pcb design?
(please also have a look at my attachment, could be helpful for your understanding.)
Thank you very much.
Best regards, NG
Solved! Go to Solution.
2021-09-20 08:59 AM
>>The issue is, now we have a leck in communication.
A what?
>>I tested out a communication system where I attached a 912600 Baud rate
921600 is the normal/classic multiple
OSC32 likely has no relationship.
The Nucleo typically derives it's 8 MHz clock from the ST-LINK on board
You need to make sure HSE_VALUE (often in stm32fxx_hal_conf.h) reflects your clock speed so the baud rate math works.
The PLL settings will also need to reflect your different clock source.
You could use the HSI+PLL on both Nucleo and your board for apple-to-apple test.
Your clock needs to start.
OVER8 and OVER16 means the UART tries to sample/synchronise with your async signal with 8 or 16 times the baud clock rate, ie 921600 x16
So the baud rate divides the APB clock by (921600 * 16) or (921600 * 8) . The higher the rate the closer you get to the APB/16 or APB/8 ceiling.
2021-09-20 08:59 AM
>>The issue is, now we have a leck in communication.
A what?
>>I tested out a communication system where I attached a 912600 Baud rate
921600 is the normal/classic multiple
OSC32 likely has no relationship.
The Nucleo typically derives it's 8 MHz clock from the ST-LINK on board
You need to make sure HSE_VALUE (often in stm32fxx_hal_conf.h) reflects your clock speed so the baud rate math works.
The PLL settings will also need to reflect your different clock source.
You could use the HSI+PLL on both Nucleo and your board for apple-to-apple test.
Your clock needs to start.
OVER8 and OVER16 means the UART tries to sample/synchronise with your async signal with 8 or 16 times the baud clock rate, ie 921600 x16
So the baud rate divides the APB clock by (921600 * 16) or (921600 * 8) . The higher the rate the closer you get to the APB/16 or APB/8 ceiling.
2021-09-20 08:09 PM
Anybody built a xls file which tells the max baud rate from the clock tolerances of both transmitter and receiver? That could be handy as cubeMX "calculator". Who would like this?
2021-09-20 08:36 PM
>>Anybody built a xls file..
As I explained to my local Excel jockey, it's not that I can't use a spreadsheet, but rather that I chose not too, I could write a fitter in a few dozen lines of C, and before spreadsheets I used a TI-59 to automate computations.
2021-09-23 07:03 AM
Highly appreciate your answers, thx!
2021-09-23 08:42 AM
I upscaled the peripherial clock speed (APB) now it's working great. (How can I switch a question to "Solved" in this forum? :) )