USB CDC ACM how to do flow control for RX data - nrf5340

Hello,

 

    I am having an esp32 connected to nrf5340 and I am doing firmware update for the esp32 by bypassing the UART of esp32 via the USB CDC ACM of nrf5340.

So basically esp32 is connected to nrf5340 via UART and the usb of nrf5340 is connected to computer. 

When I get any data in ACM I am writing it to esp32 via uart and vice versa. 

But I am not able to control the in-flow of data via USB ACM and overflow is happening. 

I need to control the flow of data from computer to nrf5340 via USB ACM, how can I do it ?

I couldn't find any CTS macro.

Parents
  • I would also very much like to know the answer to this.

    There appears to be line control handling in the uart layer and cdc_acm but I cannot find out how to receive any callback on the state of the RTS/CTS virtual linkup. I also can not find any code of this being handled in the stack and on the transmit side the tx interrupt of cdc_acm seems to be only reliant on the ring buffer being able to accept more data.

  • Hello,

    I do not believe that virtual com port (UART over USB) support flow control the same way as UART over an actual hardware COM port, instead for USB it's intended that the peer NACK communicaton if it's not able to handle the incomming data (this is done by for instance not calling uart_fifo_read() until it's able to handle the data). Alternatively you can add some overhead to the communication where you have bidirectional data to ensure that this does not happen in the first place.

    Kenneth

  • Our issue is actually the other way. The Host has troubles not corrupting our data.
    We can see classic signs of data being overwritten by newer data in the resulting datastream with unique sequences of data 32-64k further on in "time" appearing at an earlier time in the resulting data.

    At first we though we were overfilling the virtual uart but it's circular buffer does not allow for that to happen. The error happens later in the chain. Correct amount of bytes usually arrive (We transmit 32-64Mbyte size files) but data has been garbled. (On very rare occasions some bytes do get lost and total transmission received is a bit shorter.)

Reply
  • Our issue is actually the other way. The Host has troubles not corrupting our data.
    We can see classic signs of data being overwritten by newer data in the resulting datastream with unique sequences of data 32-64k further on in "time" appearing at an earlier time in the resulting data.

    At first we though we were overfilling the virtual uart but it's circular buffer does not allow for that to happen. The error happens later in the chain. Correct amount of bytes usually arrive (We transmit 32-64Mbyte size files) but data has been garbled. (On very rare occasions some bytes do get lost and total transmission received is a bit shorter.)

Children
No Data
Related