UART baud rate problem with STMF767ZI processor

[Sean Bolton]

​I have a UART on an STM32F767ZI  configured for 9600 baud. 

The baud rate of the external transmitting device is measured as 9632. I have found that the F767 is very sensitive to baud rate difference and setting the device to 9600 and 3 samples will give errors.  The measured baud rate of the F767 is 9586.  

Adjusting the F767 baud to 9700 (measured at 9681) and configuring for 1 sample removes the errors.   However the baud rate of 9586 should be within the tolerance of the UART. We are trying to understand why the UART is so sensitive to baud and samples. 

Are there any other processor/peripheral register settings that can effect how the UART bits are sampled and might account for this error. 

We have looked at the waveforms into and out of the processor pin and these are clean with no distortion.

[T J]

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.

[Sean Bolton]

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.

[Tesla DeLorean]

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.

[Sean Bolton]

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.

[Sean Bolton]

​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).

[Bob S]

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?

[Tesla DeLorean]

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.

[Sean Bolton]

​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

[Dave P]

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?