UART baud rate problem with STMF767ZI processor

are you using a crystal ?

you can buffer the internal clock output to the mco pin,

check with scope, to be sure the crystal is selected.

did you make a custom board ? just asking that the crystal has the correct capacitors...

did you hand code the main() initialisation ? or did you use the cube ?

it will be exactly 9600 baud with a crystal.

Thanks TJ

We used CUBE to generate the UART/processor config code.

We did use the internal oscillator (less accurate) but have switched to external oscillator (more accurate) but this has not resolved our issue.

It seems the internal sampling is very sensitive to baud rate error despite appearing to be within acceptable tolerance range.  So we get invalid data bytes received.  This is at 9600 baud.

​

What frequency are you clocking the part/buses?

Using 16 or 8 times over clocking mode?

You'd do better working the math on the BRR setting to find one that is most agreeable.

Not aware of the F7 being unduly fussy, but the USART design has noise and framing flags then need clearing if they get set.

Baud rates should be fairly speed tolerant, should be able to manage +/-6% error in speeds.

I have some F7's managing 9600 baud GPS streams currently, and not giving me any headaches.

Hi Clive

Thanks for the ideas.

We have a system clock (SYSCLK) of 120MHz.  BBR set to 12500​.  We have tried 8 and 16 times over sampling and also switched from mid 3 samples to mid 1 sample.  mid 1 sample appears to improve things.  And we monitor/clear the framing error flags.

It is as if the bit sampling is skewed and doesn't take place in the centre of the bit.  But I can see no reason why this should be unless either the internal signal is distorted or somehow the Rx clock alignment is shifted towards the edge of the bit.

​A long shot but do the GPIO settings (e.g. SPEED and pull up/down have any effect?)   We have SPEED set to very high and Pull to nopull (external termination).

For the Rx pin, speed should have no effect as that is only for the drive strength on output pins. Are you using "wake up from stop mode" and having to wait for clocks to spin back up (which decreases your baud rate tolerance)? Have you looked at the incoming serial line with a scope - as it goes in to the STM32 CPU? Is it noisy? Does it have a slow rise time?

Won't impact inputs, but would suggest dialing back output rates to the 1-2 MHz settings rather than 100 MHz. If you have ringing on the input you might want to consider a series resistor.

I don't think I'd want to be clocking APB2 peripherals at 120 MHz.

Not sure what you have sending the data here, but look at intersymbol gaps, and perhaps moving from 1 stop bit to 2. If the STM32 is flagging errors that would also be helpful to know. Not sure how the determination of success/failure is being made currently.

​Thanks Clive, Bob

We are going to scope the Rx pin more closely and see if we observe any issues with the input signal waveform.

Sean

We seem to be having a similar issue on an STM32F427, we have to adjust our BR up by about 1.5% to get reliable comms. No framing errors or noise flags set, it's just identifying the first stop bit as a data bit, like the sampling is lagging behind. It's tolerated at 10400 BR but is not happy at 38400.

So we have the same questions:

1) Why is the rate skewed slow?

2) Why is the rate error tolerance not as stated?

We have an external clock with a measured error of +0.015% so that's not the issue.

Changed over-sampling, stop bits, and/or 1-bit method; did nothing to the BR error.

Did you ever resolve you're problem Sean?

​In the end the root cause of our problem was the transmitting device was occasionally shortening the stop bit!  (PIC processor)  This meant that on occasion the STM micro was sampling the stop bit and getting the wrong result as the PIC processor had pulled the stop bit low too soon.

It is worth scoping the incoming signal and ensuring the timing is correct for your baud rate.  The transmitter can also effect the reliability of the comms link if its timing is also slightly out.