USIC as UART using receive buffer leaves unread characters in buffer

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
I'm trying to do a simple interrupt receiver for the UART and, while it works fairly well, I have encountered that sometimes not all characters are received, later on,
when more characters are sent, the lost characters appear, as if they have been waiting all the time in the buffer even though the buffer reported it was empty.

After several test I've found that, when using receive buffer, the interrupt only triggers when the fill level of the buffergets bigger than LIMIT. While this would seem ok,
so it helps to reduce interrupt overhead, the result is that some data may be lost.

i.e: if RBCTR.SIZE=1 (two words in buffer) and RBCTR.LIMIT=1 the receive interrupt is triggered every time the buffer holds two words. The result is that any message with an even
number of characters is received correctly while, any message with an odd number of characters is missing the last word because the interrupt will never be triggered.

Something similar will happen for RBCTR.SIZE=5 and RBCTR.LIMIT=5, all the messages that are not multiple of five in size will never be completely received, until more words
are recevied (maybe the next message)

For now I've solved the problem setting RBCTR.LIMIT to zero but this renders the buffer functionality almost useless because one interrupt per word is generated and, at high speeds,
this is not desirable.

Is there a way to recover those words still in the buffer or am I missing something?

Best Regards.
0 Likes
2 Replies
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

The behavior is normal if you do not know before hand how many data is to arrive. You will need to implement a timeout to detect that nothing is being sent anymore so you can take the remaining data on the buffer.
Otherwise if you know how much data you expect, lngeth field in a header, you can adapt the limit. See code of UART APP or CMSIS UART driver implementation for XMC.

Regards,
Jesus
0 Likes
Not applicable
Thank you for your answer. I was afraid it was as you explain.

Regretfully I cannot predict the data packet length because it depends on the payload size that is by nature variable. Adapting the limit may be a solution
but that's assuming that everything works perfect, if there are errors in the line or disconnections anything could happen. Timer sounds like a better option.

A more elegant solution would be to generate an interrupt with the RXIDLE condition but, as far as I can tell,
there is no way to generate an interrupt on RXIDLE=1 is it?

Best Regards
0 Likes