Zephyr 2.4.0 with Async UART

[Canadian_EE]

Hi, 

   I am having the same problem as nRF9160 UART: Loosing data when RxData is split into 2 buffers (Async API) - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com) and ASYNC uart and UART_RX_RDY timeout - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com). I have tried the solution, namely modifying 

uart_nrfx_uarte.c

prj.config

However, I end up with this error

Ultimately, I would like this problem resolved. If I'm missing something obvious, please let me know. 

[Canadian_EE]

Hi Susheel, 

     UART with DMA should not drop data, particularly when the buffer rolls over. In my opinion, this isn't a hardware flow control or not flow control issue. Flow control might help, but the DMA with interrupts should properly handle the buffer filling up. The fact that the ASYNC UART DMA approach doesn't work properly indicates a problem or flaw with the Nordic Zephyr ASYNC UART. The DMA should alleviate the need for for flow control by providing a continuous receive capability. 

Also, the prj.config settings do not appear to make a difference. Why is that? 

[Susheel Nuguru]

Canadian_EE said:

In my opinion, this isn't a hardware flow control or not flow control issue. Flow control might help, but the DMA with interrupts should properly handle the buffer filling up.

Well the easyDMA is not the only variable that effects the throughput of the application. The applicaiton normally have post processing latencies for every serial transaction which is more than making a new request. You need to analyze how much time is spend with every transaction of data received/sent in your application. If you are not processing the data at all (ignoring the incoming data) and only spending time in the application to reconfigure the DMA pointers, then I would understand your logic of flow control not needed with EasyDMA. You can do a simple test of lowering the baudrate on both sides and see if you see the same issue. If you do, then what I think about flow control and throughput even with Async UART is correct. If you do not see the same issue, then we can remove the flow control from our discussions.

[Canadian_EE]

Hi Susheel, 

   can you explain your comment again? I don't quite follow what you mean. 

[Simonr]

Hi Chad

Sorry about the delayed reply, but Susheel is out of office today. I'll try to rephrase.

Without EasyDMA and flow control, the receiving device will, in most applications, have to confirm that the received data is correct and process it somehow. Normally, these "post processing" for a serial transaction will take more time than what the DMA and flow control does. As he says, if you're not processing the incoming data at all and the application spends time reconfiguring the DMA pointers it wouldn't spend processing incoming data otherwise, your logic of DMA being excessive makes sense.

If you test by lowering the baud rate on both sides and still see the same issue here, the need for flow control on an asynchronous UART is correct. If not reproducible at lower baud rates we can dismiss the flow control as a possible solution.

Best regards,

Simon

[Canadian_EE]

Hi Simon, 

  thanks for your response. I think I understand. I tried receiving data at different BAUD rates, and volumes; but without flow control. I didn't find that speed was the problem. I found the system lost data when the buffer(s) filled up. If there was one buffer, data was lost when that buffer filled up. When there are two (dual) buffers, data is lost when the second buffer fills up. 

   I tried BAUD rates from 115200 to 921600.  I also found issue with UART0 at BAUD rates higher then 460800 bits / s. The data came through garbled. However, I didn't find issues with UART1 at BAUD up to 921600 bits / s. 

In my case, my "post processing" is merely copying the data and echo-ing it back. The amount of time that it takes is minimal, so I don't think I have a backup problem. At least not at this time. If my system couldn't process data fast enough, I completely agree. That would be a problem.