UART RX timing with external device

RE: UART RX timing with external device

jmerri95 — Thu, 20 Feb 2025 23:42:47 GMT

Thank you Kenneth,

I am traveling for the next week, once i am back i will give this a try.

Thank you again for your help,

Jack

RE: UART RX timing with external device

Kenneth — Thu, 20 Feb 2025 18:12:27 GMT

Hi Jack,

I think it would help if you could toggle a pin on UART_RX_STOPPED, and at the same time perform a logic analyzer trace, so we can see the last 3-4bytes that triggered the issue when the pin toggles. I suspect that would help a lot to understand the issue.

Can I assume you have used the samples/peripheral/lpuart example as guide here, and you for instance are 100% sure you are double buffering by providing a buffer every time on UART_RX_BUF_REQUEST event?

Also it would be interesting to understand what buffer size and numbers of buffers you have provided, ref the lpuart example:

#define BUF_SIZE 64
static K_MEM_SLAB_DEFINE(uart_slab, BUF_SIZE, 3, 4);

I don't know the baudrate here or the amount of data, but if you have very high baudrate (e.g. 115200 or more) I would consider increasing BUF_SIZE by 2x every time the baudrate doubles.

I would expect the default value of 10000us for the timeout to be a good value.

Kenneth

RE: UART RX timing with external device

jmerri95 — Wed, 19 Feb 2025 16:03:42 GMT

Hi Kenneth,

Thank you for the details. I dug into the UART_RX_STOPPED condition and it looks like there are two errors. One being a UART_BREAK, and the second being a UART_ERROR_FRAMING. They are both present in a single RX event.

I turned on the HFCLK, but it looks like the issue is still present. I am guessing the serial break condition and the framing condition are closely tied.

There is an idle line delay (minimum 2 bytes) from the manufacture of the external keypad. Do you have any suggestions on dealing with the serial break condition?

Thank you,

Jack

RE: UART RX timing with external device

Kenneth — Tue, 18 Feb 2025 14:45:42 GMT

Try to find out what caused the UART_RX_STOPPED conditions by checking the uart_rx_stop_reason.

I suspect that it's a mismatch in the baudrate and that is causing e.g. framing error. If that is the case, then I suspect the main cause may be that you have not started the external high frequency clock.

But you can try to increase the buffers to see if that helps, and make sure you are double buffering by calling uart_rx_buf_rsp() while current buffer is being filled up, see existing examples on how to do this. From the link I shared it says for instance:

* If uart_rx_buf_rsp is not called before current buffer
* is filled up, receiving will stop.
*/
UART_RX_BUF_REQUEST,

Kenneth

RE: UART RX timing with external device

jmerri95 — Tue, 18 Feb 2025 13:56:29 GMT

Hi Kenneth,

Thank you for getting back to me. There are three scenarios that happen:

First, TX data is sent and RX data comes back in full (roughly 45 bytes).

Second, TX data is sent and no data comes back UART_RX_RDY is not triggered.

Third, TX data is sent and partial data comes back UART_RX_RDY is triggered.

In all of these scenarios the UART_RX_STOPPED condition happens. Based on the RX timeout there are more or less of the UART_RX_STOPPED condition. The optimal RX timeout (for this application) seems to be 1500 - 2500 ms.

I have a meeting with the manufacturer of the external device later this week. They might be able to give some clues as well. I am also going to test the interrupt API to see what findings i get there.

Thank you,

Jack

RE: UART RX timing with external device

Kenneth — Mon, 17 Feb 2025 13:10:03 GMT

Hello,

Can you just go over once the description of receiving from the uart.h driver if some may apply in your case?
https://github.com/nrfconnect/sdk-zephyr/blob/v3.7.99-ncs2/include/zephyr/drivers/uart.h#L163

For instance I want to check if it's possible you have a UART_RX_STOPPED condition due to:
https://github.com/nrfconnect/sdk-zephyr/blob/v3.7.99-ncs2/include/zephyr/drivers/uart.h#L44

In such case you should for instance start to receive again, or handle it in some other way depending on what you want.

Kenneth