High Fequency UART transmissions

[User1321]

I am using the nrf52832 with its Development kit to transmit trough UART to the PC a frame with 26 bytes, I have configured the port to 1MBoudRate. Once I prepare the frame I use the next instructions to transmit:

while(nrf_drv_uart_tx_in_progress()){}; nrf_drv_uart_tx(finalframe ,26);

The intention is to transmit a new frame every 250uS which implies a frequency of 4kHz. In theory if I have settled the speed to 1MboudRate this should be possible, however, the frames are not received right, 1 of every 8 frames has a byte missing. It starts to send all bits properly when the frequency decreases to 2,5kHz.

Any idea why this could be happening? Maybe can I use another transmit function to tx using UART?

[User1321]

Ok some updates:

• I enabled flow Control and it works better, however, using the oscilloscope I see that I have a CTS signal that indicates a suspension of my UART transmission, I observe this on the data that I am receiving, some frames (around 256 bytes) are not received.
• I am using the UART driver module and initiating the UART with the function APP_UART_FIFO_INIT(...) so I assume that I am enabling the fifo OK. However, one curious thing is that I do not see any important effect when I change the size of the buffer from 1 to 1024 or vice-versa. I think that the error is related with the FIFO itself. However, I don't know if the CTS signal is settled by the uC itself or by the PC that is receiving the data through UART. Does anyone have an idea of what I am missing?

[Ole Bauck]

RTS - Ready To Send - is an output on the nRF. This pin is set high when the nRF is unable to receive more bytes.

CTS - Clear To Send - is an input on the nRF. It will be controlled by the other device (the virtual COM port on your PC in your case). If this is set high and the UART is set up to use flow control, the nRF will stop sending data.

If the flow control is working correctly you should not see any data on the TX line while CTS is high.

It sounds to me like the FIFO (app_uart_fifo) is not working correctly if it is no difference in the buffer size you set. I assume you are talking about the TX_BUF_SIZE used in APP_UART_FIFO_INIT(..). Do you get any APP_UART_FIFO_ERROR event in the uart event/error handler?

[User1321]

No, I have just checked and I don't get any APP_UART_FIFO_ERROR on the UART handler. No matter the value that I put on the TX_BUF_SIZE. The only thing is that if I put a number on TX_BUF_SIZE that is not power of 2, then the UART module does not work. But there is no difference or error if I put 1, 256 or 1024 on TX_BUF_SIZE.
What other evaluation can I do to verify if the problem is related with the FIFO?

[Ole Bauck]

I just saw in your first question that you actually don't use app_uart after initialization, but you use nrf_drv_uart directly:

while(nrf_drv_uart_tx_in_progress()){}; nrf_drv_uart_tx(finalframe ,26);

So the FIFO in app_uart_fifo is not used, which is why it does not make any difference if you set 1,256 or 1024 as the tx buffer size.

nrf_drv_uart_tx_in_progress will not return until all bytes in nrf_drv_uart_tx is sent. The transmission will be delayed if CTS line is addressed in the transfer.

Your problem is not on the nRF, but on the device in the other end of the UART. I do not have numbers on how fast the Interface/debugger chip (SEGGER chip) on the DK can send data to the computer, but your test leads me to believe that it is slower than 1MBaud (100KB/s).

You could use RTT instead, but the interface chip is limited to 1MHz which will probably not give you 100KB/s when including the overhead. Other alternatives is to use an external debugger with higher speed than 1MHz or to use another UART-to-USB chip like the FTDI.

[User1321]

But If I use the FIFO properly, couldn't this help to fix the problem? How can I use properly the FIFO? just not using the while(nrf_drv_uart_tx_in_progress()){} statement? I try that together with disabling the flow Control, and I receive frames that are not complete but not with a static number of bytes in between as before. However, here I don't see any significant change if I vary the size of the TX_BUF_SIZE which for me it does not have any sense.