UART max 80 bytes on receive is possible

[mbozic]

Hi,

got a question about UART and maximum bytes it can receive in one burst or "packet".

Using nRF52382 and SDK16.

Recently I've been developing a new app in which UART baudrate needs to be 576000. Everything is set and Rx/Tx works. Legacy mode is turned off so only easy dma is enabled in the driver.

When nRF needs to receive more than 30 bytes problems occur and APP_UART_COMMUNICATION_ERROR with code 1 keeps turning up. I've enabled hardware control for test and nRF is able to receive exactly 80 bytes correctly. If I send 81 bytes, I loose the last byte, if I send 82 bytes I loose the last 2 bytes and so on. UART FIFO is set at 256 bytes for both Rx and Tx.

 Is 80 bytes some theoretical limit or is it defined somewhere in the sdk? When hardware flow is enabled I don't get APP_UART_COMMUNICATION_ERRORs, but bytes are still missing. Anyone knows why?

And 2 bonus questions.

1.) Is libuarte really only option for faster UART and can it solve the problem above?

2.) Where to start if I wish to implement my own UART driver?

Thanks!

[Henry_Chou]

Hey! It's me. mbozic:

I have a question. It's no matter about the UART RX issue.

I think that you have better to check your cobs encode. Because your encode data the last two bytes are always  ff 00.

But if your original data contents are not zeo the COBS encode the last second byte will not be ff. Because ff means after 255 bytes is zero. But the later byte is zero. It's quite strange. Isn't it?

COBS encode algorithm is n to n+2. But yours is n to n+3.

[mbozic]

Hi Henry,

don't worry, I am forcing the 0xFF in the packet so I can easily find the end of the packet to validate it. :) It's easier to spot 0xFF and then 0x00 while sending a lot of bytes like 250+.

Edit:

Don't worry about COBS, it's the code we had for years, its tested and verified. Mine is N+3 currently because I add additional zero at the beginning of packet too for testing. You can modify COBS to your needs as long as encode follows decode and I'm not even doing a decode here, I'm just sending plain data. I could test Rx with any data since my nRF receiver does not do decoding it is only receiving data. So my problem lies in receiving not decoding.

Thanks for caring! :)

[Edvin]

So how is it going? Do you still get the overrun error? If so, I believe you are not handling the data fast enough in your event handler. Is it still the default uart event handler from the ble_app_uart? Or did you change it?

[mbozic]

Hi Edvin, Henry,

I've managed to completely resolve the issue.

I've confirmed that I can receive 255 bytes in one burst on 1Mega baud with flow control. Without flow control around 250000 is pretty much stable so our only option would be to lower the baud rate for regular UART.

Libuarte has no problems with 255 bytes at 576000, so I'm sticking with it! Many thanks to one of your engineers who provided the implementation on some other thread.

Biggest issue I had was RTT not printing all bytes it received with NRF_LOG_HEXDUMP due small NRF_LOG_MSGPOOL_ELEMENT_COUNT, and that took me to wrong direction. Lesson learned! :)

No overrun errors with libuarte! No overrun errors with flow control up to 1Mega baud. Using my own reading from uart, implemented years ago.

Thanks for support guys!