STM32F4 Handling Dip Transfer Error (RX)

I am trying to communicate with a UART peripheral using DMA for RX and TX. I use the HAL library that is provided by ST (generated using STCubeMX).

I process the UART channel with 1.5MBaud - so as not to lose any data, I set up DMA in direct mode with a circular buffer and processed half-transfer interrupts to take care of the data, and keep DMA online for more data.

The problem is that sometimes I can see in the UART Status Register that the Frame error bit is turned on, and sometimes the Overrun Error flag is also turned on.

I can handle lost bytes (using crc for structured packets), but the problem is that the peripheral stops receiving data, but DMA does not cause an error or stops the transfer.

So, if I try to get data, and the flag in the system freezes.

I saw that the HAL provides a __weak function that should handle a UART_Error, but it is never called - and the status in the HAL descriptor remains normal. just looking at the register can say that there is a problem.

How do I detect / handle such errors?

thanks

+5
source share
1 answer

I do not use HAL for performance reasons, as it is very awkward and - imo also does not provide much abstraction to justify this. Hardware processing is not much more complicated; especially since you still need to have a good understanding of what is happening. And, as you already discovered, HAL only supports a specific approach; as soon as you follow your own path, you will be lost.

You seem to have similar problems as the overflow flag is set. After such an error, you should re-synchronize the receiver with the transmitter downstream after the error as a whole. This would require out-of-band signaling using a symbol or line condition not occurring in the packet. Crop errors are a good indicator; there are problems with synchronization with the beginning of a character (start bit).

If the line is clean (and not EMC problems), there should be no cropping errors or data distortions (if the synchronization parameters do not match).

If you use simple ping pong, it may take a while. However, the correct solution depends on the protocol. A good protocol design allows for transmission and overflow errors.

Note that you need to enable receive error traps in addition to DMA transmissions for information. However, if you use a timeout (and ping-pong protocol), you can simply erase the flags, as the data did not seem to be reached on time. If in fact the use of error interrupts should also be aware of the racing conditions.

+2
source

All Articles