Problem with STM32L4 USART and RS485. MCU misreads bytes in the line

[GDeto]

Problem is solved when I put termination resistors in the stard and end of the bus but when I do not do I have a strange behavior of the MCU that I cannot explain/understand.

Below you see the screenshot of Yellow: RS485 bus, Blue: The RX Line on the MCU.

This is a 115200 Baudrate, Even Parity, 1 Stop Bit, 8 bit communication.

All the bytes are translated correctly every time (10mil messages exchanged) BUT the very last one sometimes it is not interpreted correctly.

You see that the oscilloscope finds this message as 0x04 or 0b00100000.

The MCU finds it 0x82 or 0b01000001. I looks like shifted by one bit to the left, including its parity bit.

I consider that this is caused by the glitch at the end of the message.... but if you see this is after the stop bit! So I do not really understand this behavior...

I am not using DMA, this is a byte by byte reading, and a quick interrupt handler.

It is true that the overrun flag is triggered but I cannot really tell why..

This is when the last byte is not received properly

This is when the last byte is received properly.

So my main question is...

Since this is coming from the datasheet of the MCU:

Why something in the Next Start bit which is clearly not valid is overwriting my message creating an overrun error?

Kind Regards,

Georgios Detorakis

[waclawek.jan]

HSI is not precise enough. When receiving a longer string of characters transmitted back-to-back by a precisely timed transmitted, using USART with clock slow enough that the error within one frame accumulates to more than half a bit time (and perhaps even slightly less, depending on how exactly the startbit detection is implemented), starts gradually shifting out the startbit detection into the next frame's startibit, and the error accumulates across the subsequent frames, up to the point when the startbit is detected actually inside the first data bit. At that moment the next frame is received shifted one bit.

Solution is simple and definitive: use HSE, get a crystal.

Or, if you are willing to undergo the torture, fine-tune the RC oscillators from whatever precision timing source you may have (e.g. LSE), or autobaud the USART.

JW

[GDeto]

Hello Jan,

thank you for the response. I also consider that it is preferred to use an external oscillator.

However if you take a look on the two pictures I attached before it is clear that there is no drifting on the clock.

It is a rather BIG change on the last character, at least this is how I interpret it.

You see the consistency of the Green Signal that it toggles every time there is a new stop bit, for all except on the last character when the glitch is present.

If there was a drift I would expect that the whole Green Signal would have been slightly shifted but it only happens for the last character. I zoomed in, they always fall exactly on the same spot...

Regards.

[GDeto]

Honestly it is the SysTick every 1ms and clearing the Watchdog there.. Nothing else that I am aware of..

Additionally the USART are the only with the 0 Priority so I would expect that it fires fast.

It looks as it fires fast though unless there is this glitch at the end

[waclawek.jan]

Okay, so what does it take to make an experiment?

Transmit from your UART - or another UART set to the same baudrate from the same clock source - and measure how long it takes.

And/or decrease the set baudrate by cca 5%, i.e. set it to 109440 Baud.

JW

[Piranha]

You are looking at the purple signal with an oscilloscopes accurate clock, but MCU is "looking" at it with it's HSI clock. When the shift on last data bit happens, the parity bit will still be one, because it will be captured at stop bit's time. The green line delay could be some internal logic delay related to parity mismatch.

[GDeto]

I put the Termination Resistor so the line is free of glitches.

So changing to 5% it really did not work

It was detecting start bits everywhere...

Changing to 1-2% it had a very stable communication

Regarding the Timings on the MCU.

This return message from the MCU was measured 4.99ms

This was a 52 bytes transfered each having 11bits ( Start Bit, 8 bits Info, 1 bit Parity, 1 bit Stop ) + assertion-deassertion time.

Theoretical value was calculated to 4.985us. This gives a 0.1% difference from what it should be.... I cannot believe that this is a problem of the RC.

My question is related to the Interrupt Latency. How is it possible that this glitch can cause a trouble with the the interrupt routine? I cannot see how any other part of the firmware can cause this delay to occur, there is literally nothing running in the background other than the SisTyck with priority 3 that clears the Watchdog.

And how can it sees it as an overrun if there are no more bytes in the line? It misinterpreted the glich to the startbit which does not comply with the graph in the datasheet.

[kkoutso]

Hi @GDeto​ ,

did you find any solution?

I am experiencing sth similar. 40ms after a break condition @9600.8N1 on the uart line the next byte (0x54) is captured as 0xF5. I can probe on the RX pin of the STM32 with usb2uart cable and see that the byte reaching that point is indeed 0x54.

Thanks.

[Daniel_EDF]

We have exactly the same problem here after we swapped the controller from F103 to L431 on a board. After investigating the problem more closely, we are very sure that it is a problem with the UART/USART peripheral. A short pulse during the stop bit often results in the last byte not being recognized correctly. As a solution for the problem, we change the UART configuration to 0.5 stop bits during reception and to the desired setting during transmission.

We have set up a project that reproduces exactly this error on a NUCLEO L476 board:

https://github.com/DerDan/Stm32L4_UART_Glitch.git

[Garnett.Robert]

Hi,

Have you tried DMA.

I use DMA whenever I process data streams from UARTS and haven't had any issues, although I haven't done any RS485.

I use the modbus timeout feature to signal end of frame for reception.

Regards

Rob.

[Daniel_EDF]

Hi,

We use DMA in our production code, which is where we first observed the behavior.
We do not use DMA in the project to find the error. In this troubleshooting project, exactly one UART frame is generated using a pattern generator. This one byte is always received. However, sometimes incorrect if the UART frame is disturbed with a glitch within the stop bit. This glitch is created using the pattern generator.

We looked at the generated pattern with the oscilloscope:
However, you can only see the signal around the stop bit.

• yellow: a signal which is high over the entire UART byte.
• green: the generated UART byte with the glitch
• red: high if the glitch at this position resulted in an error (from the previous runs)
• blue: a statistcal represtation via DAC (from the previous runs)

Based on the investigations we have carried out, we are absolutely certain that there is a bug in the USART/UART Peripheral