• State Not Answered
  • Replies 17 replies
  • Subscribers 67 subscribers
  • Views 2320 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 315220
Options

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. 

Parents
  • 0

    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

  • 0 in reply to Simonr

    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. 

  • 0 in reply to Canadian_EE
    Canadian_EE said:
    I didn't find issues with UART1 at BAUD up to 921600 bits / s. 

    So barely changing the instance from UART0 to UART1 fixes the issue? no garbled data? No other change at all? That is interesting. Can you please double check that changing the instance number from uart0 to uart1 is the only change you do?

    If that is the case, then there might be more differences in the instance handling than I thought. In that case, please attach the project here so that I can reproduce that here.

Reply
  • 0 in reply to Canadian_EE
    Canadian_EE said:
    I didn't find issues with UART1 at BAUD up to 921600 bits / s. 

    So barely changing the instance from UART0 to UART1 fixes the issue? no garbled data? No other change at all? That is interesting. Can you please double check that changing the instance number from uart0 to uart1 is the only change you do?

    If that is the case, then there might be more differences in the instance handling than I thought. In that case, please attach the project here so that I can reproduce that here.

Children
Related