Recovery from a U(S)ART Framing Error

[John Craven]

Posted on July 06, 2018 at 00:04

I have a F446RE, with 5 devices connected to USART1,USART3,UART4,UART6,USART6

In each case, i have DMA reception configured, each with decent size buffer.

A have a 3 device versions, 2 work without issue, but model seems to be generating a framing error on a pretty regular basis. Unfortunately, i do have to be able to handle the device version seem a bit faulty.

I have configured interrupts and a callback to trap and handle u(s)art errors.

I am wondering what the best practice for resetting/restarting, my circular DMA reception.

Is there specific cleanup i need to do before restarting the DMA receive?

#uart #dma #usart #framing-error

[waclawek.jan]

Posted on July 06, 2018 at 00:47

The DMA is to be used as a circular buffer/FIFO. At reception, NDTR represents the head pointer and a variable mainatined by the pulling software is the tail, the pulling software ought to pull until tail matches head (keeping in mind the various

https://community.st.com/0D50X00009XkhAxSAJ

of the DMA). As the UART is unfortunately not organized so that you can store/associate a particular byte with the FE, the best way is to purge the whole buffer, i.e. the pulling software, when recognizing the FE, should simply set tail to head. This of course assumes that there's either some framing/packeting in the UART data or some other possibly off-band framing (extra signal) present on which the communication can resume.

JW

[T J]

Posted on July 06, 2018 at 00:47

never reset the DMA, you have it in circular mode ?

are you using crystals ? you may be suffering from clock frequency drift

did you check the errant stream on a scope ? you should be able to read the byte time, maybe see the jitter...

[John Craven]

Posted on July 06, 2018 at 01:11

I am using NUCLEO 446 RE board. I am using the HSE from the STLINK.

All the devices are sending the same frames at 125Kbaud.

i have checked the errors with a logic analyzer.

my logic analyzer sees the same framing errors when it tries to decode the frames.

When i check manually and automatically (logic analyzer), the baud rate is fine.

The framing errors are always at the beginning of each message 99% of the time.

Third trace purple is when i get the FE error interrupt.

First trace is good.

Second trace is missing about half of the 0x3E, 0x01 header, 

The balance of message is synchronized.

I ran for days with the other two version of the device with no errors or issues.

Today i added tried the remaining device flavour and the errors occur.

I have tried 3 different unit of this version. The all have the same framing issue.

Pretty sure the issue is the one device variant.

Errors occur about once every 20s (about every 2000 messages or 88000 bytes)

And i am just going to have to figure out how to negotiate the errors.

[T J]

Posted on July 06, 2018 at 01:29

125KHz is not slow.

which board is sending the rubbish ?, maybe you can work on that.

Pretty sure the issue is the one device variant.

can you elaborate on that ?

I am using NUCLEO 446 RE board. I am using the HSE from the STLINK.

can you use a real crystal ?

did you make a custom board without a crystal ?

[John Craven]

Posted on July 06, 2018 at 03:47

The devices are 3rd party. No control over them.

the device versions that do work are based on atmel 328p at 16mhz.

The newer device version that is generating framing errors has a stm32f302! Lol

[T J]

Posted on July 06, 2018 at 03:52

is that F302 not under your control ?  send it back

[John Craven]

Posted on July 06, 2018 at 04:35

I think I was pretty clear! Not my devices. No control. Have to use them. Not my choice.

I have reported the issue to the vendor. I am not expecting anything to change fast.

I need to handle the issue, hence the original question...

I can further add, that my buffer following/processing code is always finished the last message, so when the error occurs (always at the beginning of a new frame), the only data that is lost is the current message.  While not ideal, the loss of 1 in 2000 messages is not critical to the data consuming process.

So back to the original intent;

Do I need to clean up the uart/dma settings, reset anything, before I simply restart the dma reception?

[T J]

Posted on July 06, 2018 at 04:47

as

Waclawek.Jan

has said:

As the UART is unfortunately not organized so that you can store/associate a particular byte with the FE, the best way is to purge the whole buffer