# Possibility for UART receive data loss?

In a lot of examples using STM32, HAL, where UART data is received by interrupt the code looks like:

Initially (to start the receiving):

HAL_UART_Receive_IT(&huart1, Rx_data, 1);


When an interrupt receive is complete:

//Interrupt callback routine
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
...
}


I am wondering, is there a possibility that bytes are lost between the actual receiving and after the (receive complete) callback where the interrupt is started again.

Or is it assumed the interrupt handler above is so short the data will still be in the UART buffer?

• The serial communication speed is several orders slower than the code execution speed. So if no extensive processing is done in between, you should not worry about this. And a typical UART usually has some FIFO buffer, so if something missed in one processing batch, it will be picked up on the next one. – Eugene Sh. Nov 10 '17 at 17:45
• @EugeneSh. Thank you ... one worry less now :-) (I just want to understand why, and now I know). – Michel Keijzers Nov 10 '17 at 17:49
• Surely if you process the data slower than it comes you will eventually loose some. It's not that you shouldn't worry about this :) – Eugene Sh. Nov 10 '17 at 17:50
• @EugeneSh. True ... but I'm intending to just store it in a ring buffer, and let the main control loop (outside the interrupt) process it, which might take (much) longer in some cases. – Michel Keijzers Nov 10 '17 at 17:52
• Unless you use flow control with UART, of course, there is a theoretical possibility that data arrives faster than is processed. But, well, it takes some time to receive the next byte on the UART. DMA may have lower cost than an interrupt and can work with a ring buffer too. – A.K. Nov 10 '17 at 18:08

H/W flow control between UART's RTS/CTS with 16 byte Rx buffers are intended to prevent overflow. But it useful to include parity to improve signal integrity in case flow control latency is too long.

When demanding low error rates with software retry or data filtering or testing max data rates in noisy environments, it is useful to enable parity.

It is also beneficial to check for ; stop bit errors, buffer overflow errors and test with simulated environmental noise. (ESD, RF pulses , SMPS CM noise etc. lack of earth grounds etc. )

• Thank you very much .... I'm using MIDI so I cannot change parity (off), or stop bits. For ESD I have ferrite beads, I have no experience for RF pulses, SMPS CM noise and earthing is via the default pins of the MIDI connector). – Michel Keijzers Nov 10 '17 at 19:23

The interrupt driven UART communication is probably about 50 - 60 lines of the code using the registers. HAL is a huge black hole - who knows what is inside?

For MIDI you do not have too much option but in general it is good to have some kind of the protocol with the CRC at the end of every packet (many STM micros have the CRC hardware built in).

• As far as I know you can just step through the entire HAL code, so I don't think it's a black hole. I fully agree about your last part. – Michel Keijzers Nov 10 '17 at 19:48
• It is. Don't you have anything more interesting to do than stepping through this bloatware? But if you start to step through some more complicated peripherals and you see how bad that code is - the 'bin' icon starts to be the only viable solution. IMO - leave the black hole - do the proper uC programming. – 0___________ Nov 10 '17 at 20:06
• The problem is that I have not much experience with microprocessors ... just a bit with STM32 and a bit more with Arduino (using the default libraries which probably are the same kind of what you call bloatware). Btw, I'm sure that the HAL library contains a lot of generic code that is not needed when code can be made for specific goals. – Michel Keijzers Nov 10 '17 at 20:45