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!

[mbozic]

Hi Edvin,

process_uart() function is called in main while loop.

// Enter main loop.
while (1)
{
    NRF_LOG_PROCESS();
    process_uart();
}

I'll test with ble_app_uart.

I'm also evaluating our custom hardware where this is being run. I also doubt as Henry it's something in nRF SW or HW, it's probably something with our side of HW. I'll know more in few days.

Thanks for info!

[mbozic]

Okay, first I've checked the hardware, for the 10th time, could not found errors.
Then I compiled and run ble_app_uart, getting the same results!
Then I went ballistic...Placed logging all over the place and eventually I figured all data are received, only NRF_LOG_HEXDUMP was printing first 80 bytes!
Changed NRF_LOG_MSGPOOL_ELEMENT_COUNT from 8 to 64 and everything prints! I can receive up to 256 bytes with no problems at baudrates of 115200 and 250000. Bloody hell...

After that it was time to see why UART gave comm errors (overrun) at 576k baudrate, so I connected oscilloscope and another FTDI to se what I am transmitting and receiving. Transmitted data is valid, so is the received data. But, nRF does not receive more than 33 bytes at 576k.

Not sure if image will be visible correctly but I always get overrun error on UART if I send more than 33 bytes.

I would assume this is because I don't use flow control?

I will try with flow control just to verify the issue and I will try libuarte again to se if that library helps. Main problem is we can't have flow control. So I would guess our only option would be to lower the baudrate.

[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?