UART package length problems nRF VS Code SDK2.0.0

RE: UART package length problems nRF VS Code SDK2.0.0

AscherA — Wed, 05 Oct 2022 11:11:34 GMT

Hi Susheel Nuguru

I am sorry for the late reply. We managed to fix the problems by adding a new command detection in the UART_RX_RDY event structure. In the end the downgrade of the baudrate already fixed most of the major problems and since all of our commands end with "}\r\n" we where able to successfully detect our commands with a strstr string search at a certain command length or if the length stays at 1 and no other event can be detected.

Thank you for your help.

Best regards,

Andreas

RE: UART package length problems nRF VS Code SDK2.0.0

Susheel Nuguru — Thu, 29 Sep 2022 10:12:33 GMT

[quote user="AscherA"]but the other 30% of the time the UART_RX_RDY event reports that it has only received 1 byte, but actually the whole message was already received and is present in the
"evt->data.rx.buf".[/quote]

Hmm, interesting, Do you think that the UART driver is only reporting UART_RX_RDY event with 1 byte size buffer and not reporting UART_RX_RDY event for the other bytes?

Is it possible that the UART driver is using the same buffer for received data to generate future event aswell and your application is just sniffing the evt->data.rx.buf a bit early to know that the meaninful data is already there?

RE: UART package length problems nRF VS Code SDK2.0.0

AscherA — Thu, 29 Sep 2022 09:41:09 GMT

Hi,

the change in baudrate from 115200 to 9600 solved the problem with the missing bytes of the certificates. Thanks seems your theory was right.

Unfortunately another problem has been created with the change. 60% of the time the receiving works fine. The only difference is that now each byte is recognized via the UART_RX_RDY event and the command is assembled byte by byte.

This in its own is no problem, but the other 30% of the time the UART_RX_RDY event reports that it has only received 1 byte, but actually the whole message was already received and is present in the
"evt->data.rx.buf".

I tried to go down again with the baudrate, but this also did not solve this problem. DO you have any suggestions on how to takle this particular problem?

Best regards,

Andreas

RE: UART package length problems nRF VS Code SDK2.0.0

Susheel Nuguru — Tue, 27 Sep 2022 19:36:34 GMT

Andreas, as you may already know, sometimes it is not just enough to have a large buffer size in the application buffers. The bottle necks could be post processing of the received data that might be slower than the speed with which the data is coming into RX buffers.

One easy way to test if this is the case is to decrease the uart speed (baudrate) on both ends and see if you the do not miss any data. If you do not miss any data on slower baudrate, then we can confirm our theory.

RE: UART package length problems nRF VS Code SDK2.0.0

AscherA — Tue, 27 Sep 2022 11:09:13 GMT

Hi Susheel Nugru,

Thanks for your help.
Yes you are right we are not using hardware flow control. Due to pin restrictions we probably also will not be able to implement hardware flow control in our normal application. Our UART Configuration looks like this:

# Uart Config
CONFIG_SERIAL=y
CONFIG_NRFX_UARTE0=y
CONFIG_UART_ASYNC_API=y

I will implement the hardware flow control in a new test application to verify if this would solve our problem. The variable "BUF_SIZE" in our UART communication has a value of 4096.

RE: UART package length problems nRF VS Code SDK2.0.0

Susheel Nuguru — Tue, 27 Sep 2022 10:20:37 GMT

[quote user=""]For example a certificate command is 1736 bytes long and the received length is 1721.[/quote]

Can you show me how your application is configuring the UART? Is it using hardware flow control? This kind of symptoms seems very likely when there is no hardware flow control and when the receive buffers overflow, the application most likely does not have a handshake mechanism to ask the peer to resend the overflowed bytes.