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.

[Sean Bolton]

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

[Dave P]

Our problem seems to be on both Rx and Tx. Scope trace shows timing is about right but 1.5% difference in timing is not easily measurable.

For the protocol we're using, when the 1st stop bit goes high we're sometimes reading that as the leading bit (=1), as though we're sampling late. I thought maybe the start bit was too short but it looks OK. So it sounds like you had a different issue. Were you able to get around your problem from the ST side or were you able to modify the PIC side?

I guess I need a baud rate detection tool or a frequency analyzer to determine whether it's the ST or the other device that is off. But that still won't explain why the tolerance is so tight.

Thanks anyway for the reply.

[Tesla DeLorean]

Not having issues with STM32 UART here, and work a lot with devices streaming serial data.

On PC's when I've had sync issues with some receiver equipment (not STM32 stuff, legacy RS232 based gear) I've found 1.5 and 2 stop-bit settings to be helpful. Some things are just happier with more leisurely inter-symbol packing, and days when processors ran at 4 MHz, not 400 MHZ or 4 GHz

[Sean Bolton]

We were able to modify the PIC end of the link and extend the stop bit so it is always within tolerance (we just made it effectively a 1.5x stop bit length which stopped it ever being too short).

Your problem could be timing if you think the stop bit is being seen as a start bit. Maybe experiment with different length stop bits to see the effect, and maybe parity too.

We had a very clear short STOP bit which we could capture and see on the scope. 1.5% error is less easy to spot but if you can capture the Tx/Rx waveforms you can measure the full byte period and see what this looks like.

Good luck debugging....

Sean