USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

Hieu — Mon, 04 Dec 2023 13:19:56 GMT

Hi Peter,

I tried to get Linux working but wasn't very successful. I admittedly didn't try that much though, because I decided to fall back to the Python options.

With Python, I was able to reproduce some problems... The state machine in usb.c resulted in app_usbd_cdc_acm_read_any() being called even when the transmission is over, which leads to an infinite loop where app_usbd_cdc_acm_read_any() would return 8, NRF_ERROR_INVALID_STATE.

Furthermore, I see that with both the working_sample and not_working_sample...

This test was run with usb-test-packed-2.tgz with these modifications:

A 5000ms delay after usb_config() in main.c, as discussed in this reply.
usb.c::usb_read_buf() to not flush the log, as suggested by my colleague in this reply.
usb.c::usb_read_buf() to let the debugger stop the execution if app_usbd_cdc_acm_read_any() starts returning 8 too many times.

Due to circumstances, I will be away from DevZone for the several weeks. However, I have made sure that another engineer will be arranged to support you.

I am really sorry that it has taken so much time and I essentially hasn't been able to help at all.

Below are overviews of my work and all related files attached, for both your and Susheel's references.

Python 3 script:

# Require pyserial ~3.5. Installs with `pip install pyserial`
import serial

working_sample =        "ABC00DEFGHIJKLMNOP;ABC01DEFGHIJKLMNOPQR;ABC02DEFGHIJKLMNOPQR;ABC03DEFGHIJKLMNOPQR;ABC04DEFGHIJKLMNOPQR;ABC05DEFGHIJKLMNOPQR;ABC06DEFGHIJKLMNOP;ABC07DEFGHIJKLMNOPQR;ABC08DEFGHIJKLMNOPQR;ABC09DEFGHIJKLMNOPQR;ABC10DEFGHIJKLMNOPQR;ABC11DEFGHIJKLMNOP;ABC12DEFGHIJKLMNOPQR;ABC13DEFGHIJKLMNOPQR;ABC14DEFGHIJKLMNOPQR;ABC15DEFGHIJKLMNOP;ABC16DEFGHIJKLMNOPQR;ABC17DEFGHIJKLMNOPQR;ABC18DEFGHIJKLMNOPQR;ABC19DEFGHIJKLMNOP;ABC20DEFGHIJKLMNOP;ABC21DEFGHIJKLMNOP;ABC22DEFGHIJKLMNOP;ABC23DEFGHIJKLMNOP;ABC24DEFGHIJKL;ABC26DEFGHIJKL;ABC27DEFGHIJKL;ABC28DEFGHIJKL;ABC29DEFGHIJKL;ABC30DEFGHIJKLM;ABC31DEFGHIJKLM;EOT;"
not_working_sample =    "ABC00DEFGHIJKLMNOP;ABC01DEFGHIJKLMNOPQR;ABC02DEFGHIJKLMNOPQR;ABC03DEFGHIJKLMNOPQR;ABC04DEFGHIJKLMNOPQR;ABC05DEFGHIJKLMNOPQR;ABC06DEFGHIJKLMNOP;ABC07DEFGHIJKLMNOPQR;ABC08DEFGHIJKLMNOPQR;ABC09DEFGHIJKLMNOPQR;ABC10DEFGHIJKLMNOPQR;ABC11DEFGHIJKLMNOP;ABC12DEFGHIJKLMNOPQR;ABC13DEFGHIJKLMNOPQR;ABC14DEFGHIJKLMNOPQR;ABC15DEFGHIJKLMNOP;ABC16DEFGHIJKLMNOPQR;ABC17DEFGHIJKLMNOPQR;ABC18DEFGHIJKLMNOPQR;ABC19DEFGHIJKLMNOP;ABC20DEFGHIJKLMNOP;ABC21DEFGHIJKLMNOP;ABC22DEFGHIJKLMNOP;ABC23DEFGHIJKLMNOP;ABC24DEFGHIJKL;ABC26DEFGHIJKL;ABC27DEFGHIJKL;ABC28DEFGHIJKL;ABC29DEFGHIJKL;ABC30DEFGHIJKLM;EOT;"


def send_message(port, message):
    # Configure serial port
    ser = serial.Serial()
    ser.baudrate = 9600  # Set baud rate to 9600
    ser.timeout = 5  # Set timeout to 1 second
    ser.port = port

    try:
        # Open the serial port
        ser.open()
    except serial.SerialException as e:
        print("Could not open serial port: {}".format(str(e)))
        return

    # Write the message to the serial port
    try:
        ser.write(message.encode())
    except Exception as e:
        print("Could not write to serial port: {}".format(str(e)))
    finally:
        # Close the serial port
        ser.close()


def main():
    send_message("COM30", working_sample)
    # send_message("COM30", not_working_sample)


if __name__ == '__main__':
    main()

One sample RTT log when tested with working_sample string:

<info> app: APP_USBD_EVT_POWER_DETECTED
<info> app: Try NOP command to see if USB is connected ...
.<info> app: APP_USBD_EVT_POWER_READY
<info> app: APP_USBD_EVT_STARTED
..<info> app: APP_USBD_EVT_DRV_SUSPEND
.<info> app: APP_USBD_EVT_DRV_RESUME
..........................................................................................<info> app:
Get items ...
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 29
<info> app: m_rx_buffer: ABC00DEFGHIJKLMNOP;ABC01DEFGH
<info> app: resp: ABC01DEFGH (resp_len: 10)
<info> app: row: ABC00DEFGHIJKLMNOP; (resp_len: 10, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 19
<info> app: m_rx_buffer: IJKLMNOPQR;ABC02DEF
<info> app: resp: ABC02DEF (resp_len: 8)
 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 16
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC
<info> app: resp: ABC (resp_len: 3)
<info> app: row: ABC02DEFGHIJKLMNOPQR; (resp_len: 3, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 26
<info> app: m_rx_buffer: 03DEFGHIJKLMNOPQR;ABC04DEF
<info> app: resp: ABC04DEF (resp_len: 8)
 0)
<info> app: NRF_SUCCESS: rx_size = 21
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC05DEF
<info> app: resp: ABC05DEF (resp_len: 8)
<info> app: row: ABC04DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 17
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC0
<info> app: resp: ABC0 (resp_len: 4)
<info> app: row: ABC05DEFGHIJKLMNOPQR; (resp_len: 4, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
_RX_DONE: rx_size = 25
0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 19
<info> app: m_rx_buffer: IJKLMNOPQR;ABC08DEF
<info> app: resp: ABC08DEF (resp_len: 8)
<info> app: row: ABC07DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 20
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC09DE
<info> app: resp: ABC09DE (resp_len: 7)
<info> app: row: ABC08DEFGHIJKLMNOPQR; (resp_len: 7, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 21
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC11DEF
<info> app: resp: ABC11DEF (resp_len: 8)
<info> app: row: ABC10DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 21
<info> app: m_rx_buffer: GHIJKLMNOP;ABC12DEFGH
<info> app: resp: ABC12DEFGH (resp_len: 10)
<info> app: row: ABC11DEFGHIJKLMNOP; (resp_len: 10, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 21
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC14DEF
<info> app: resp: ABC14DEF (resp_len: 8)
<info> app: row: ABC13DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 21
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC15DEF
<info> app: resp: ABC15DEF (resp_len: 8)
 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 3
<info> app: m_rx_buffer: GHI
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 18
<info> app: m_rx_buffer: JKLMNOP;ABC16DEFGH
<info> app: resp: ABC16DEFGH (resp_len: 10)
<info> app: row: ABC15DEFGHIJKLMNOP; (resp_len: 10, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 6
<info> app: m_rx_buffer: GHIJKL
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 15
<info> app: m_rx_buffer: MNOPQR;ABC19DEF
<info> app: resp: ABC19DEF (resp_len: 8)
<info> app: row: ABC18DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 21
0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 19
<info> app: m_rx_buffer: IJKLMNOP;ABC21DEFGH
<info> app: resp: ABC21DEFGH (resp_len: 10)
<info> app: row: ABC20DEFGHIJKLMNOP; (resp_len: 10, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 9
<info> app: m_rx_buffer: IJKLMNOP;
<info> app: resp:  (resp_len: 0)
)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 29
<info> app: m_rx_buffer: ABC22DEFGHIJKLMNOP;ABC23DEFGH
<info> app: resp: ABC23DEFGH (resp_len: 10)
<info> app: row: ABC22DEFGHIJKLMNOP; (resp_len: 10, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 19
<info> app: m_rx_buffer: IJKLMNOP;ABC24DEFGH
0)
<info> app: NRF_SUCCESS: rx_size = 16
<info> app: m_rx_buffer: IJKL;ABC26DEFGHI
<info> app: resp: ABC26DEFGHI (resp_len: 11)
<info> app: row: ABC24DEFGHIJKL; (resp_len: 11, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 18
<info> app: m_rx_buffer: JKL;ABC27DEFGHIJKL
<info> app: row: ABC26DEFGHIJKL; (resp_len: 14, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 15
<info> app: m_rx_buffer: ;ABC28DEFGHIJKL
<info> app: resp: ABC28DEFGHIJKL (resp_len: 14)

<info> app: NRF_SUCCESS: rx_size = 15
<info> app: m_rx_buffer: ;ABC29DEFGHIJKL
<info> app: resp: ABC29DEFGHIJKL (resp_len: 14)
<info> app: row: ABC28DEFGHIJKL; (resp_len: 14, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 15
<info> app: m_rx_buffer: ;ABC30DEFGHIJKL
<info> app: resp: ABC30DEFGHIJKL (resp_len: 14)
<info> app: row: ABC29DEFGHIJKL; (resp_len: 14, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: m_rx_buffer: M
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: APP_USBD_CDC_ACM_USER_EVT_PORT_CLOSE
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 0
<info> app: m_rx_buffer:
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8

// Breakpoint hit

One sample RTT log when tested with not_working_sample string:

<info> app: APP_USBD_EVT_POWER_DETECTED
<info> app: Try NOP command to see if USB is connected ...
.<info> app: APP_USBD_EVT_POWER_READY
<info> app: APP_USBD_EVT_STARTED
..<info> app: APP_USBD_EVT_DRV_SUSPEND
.<info> app: APP_USBD_EVT_DRV_RESUME
......................................................................<info> app:
Get items ...
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 29
<info> app: m_rx_buffer: ABC00DEFGHIJKLMNOP;ABC01DEFGH
<info> app: resp: ABC01DEFGH (resp_len: 10)
<info> app: row: ABC00DEFGHIJKLMNOP; (resp_len: 10, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 19
<info> app: m_rx_buffer: IJKLMNOPQR;ABC02DEF
<info> app: resp: ABC02DEF (resp_len: 8)
<info> app: row: ABC01DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 16
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC
 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 26
<info> app: m_rx_buffer: 03DEFGHIJKLMNOPQR;ABC04DEF
<info> app: resp: ABC04DEF (resp_len: 8)
<info> app: row: ABC03DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 17
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC0
<info> app: resp: ABC0 (resp_len: 4)
<info> app: row: ABC05DEFGHIJKLMNOPQR; (resp_len: 4, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 25
<info> app: m_rx_buffer: 6DEFGHIJKLMNOP;ABC07DEFGH
0)
<info> app: NRF_SUCCESS: rx_size = 19
<info> app: m_rx_buffer: IJKLMNOPQR;ABC08DEF
<info> app: resp: ABC08DEF (resp_len: 8)
<info> app: row: ABC07DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 20
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC09DE
<info> app: resp: ABC09DE (resp_len: 7)
<info> app: row: ABC08DEFGHIJKLMNOPQR; (resp_len: 7, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 22
<info> app: m_rx_buffer: FGHIJKLMNOPQR;ABC10DEF
<info> app: resp: ABC10DEF (resp_len: 8)
 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 21
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC11DEF
<info> app: resp: ABC11DEF (resp_len: 8)
<info> app: row: ABC10DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 19
<info> app: m_rx_buffer: IJKLMNOPQR;ABC13DEF
<info> app: resp: ABC13DEF (resp_len: 8)
<info> app: row: ABC12DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 21
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC14DEF
 0)
<info> app: NRF_SUCCESS: rx_size = 21
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC15DEF
<info> app: resp: ABC15DEF (resp_len: 8)
<info> app: row: ABC14DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 3
<info> app: m_rx_buffer: GHI
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 18
<info> app: m_rx_buffer: JKLMNOP;ABC16DEFGH
<info> app: resp: ABC16DEFGH (resp_len: 10)
0)
<info> app: NRF_SUCCESS: rx_size = 19
<info> app: m_rx_buffer: IJKLMNOPQR;ABC17DEF
<info> app: resp: ABC17DEF (resp_len: 8)
<info> app: row: ABC16DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 21
<info> app: m_rx_buffer: GHIJKLMNOPQR;ABC18DEF
<info> app: resp: ABC18DEF (resp_len: 8)
<info> app: row: ABC17DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: m_rx_buffer: GHIJKL
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 15
<info> app: m_rx_buffer: MNOPQR;ABC19DEF
<info> app: row: ABC18DEFGHIJKLMNOPQR; (resp_len: 8, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 21
<info> app: m_rx_buffer: GHIJKLMNOP;ABC20DEFGH
<info> app: resp: ABC20DEFGH (resp_len: 10)
0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 19
<info> app: m_rx_buffer: IJKLMNOP;ABC21DEFGH
<info> app: resp: ABC21DEFGH (resp_len: 10)
<info> app: row: ABC20DEFGHIJKLMNOP; (resp_len: 10, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 9
)
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 29
<info> app: m_rx_buffer: ABC22DEFGHIJKLMNOP;ABC23DEFGH
<info> app: resp: ABC23DEFGH (resp_len: 10)
<info> app: row: ABC22DEFGHIJKLMNOP; (resp_len: 10, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 19
<info> app: m_rx_buffer: IJKLMNOP;ABC24DEFGH
<info> app: resp: ABC24DEFGH (resp_len: 10)
0)
<info> app: NRF_SUCCESS: rx_size = 16
<info> app: m_rx_buffer: IJKL;ABC26DEFGHI
<info> app: resp: ABC26DEFGHI (resp_len: 11)
<info> app: row: ABC24DEFGHIJKL; (resp_len: 11, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT_RX_DONE: rx_size = 18
<info> app: m_rx_buffer: JKL;ABC27DEFGHIJKL
<info> app: resp: ABC27DEFGHIJKL (resp_len: 14)
<info> app: row: ABC26DEFGHIJKL; (resp_len: 14, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 15
<info> app: m_rx_buffer: ;ABC28DEFGHIJKL

<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 15
<info> app: m_rx_buffer: ;ABC29DEFGHIJKL
<info> app: resp: ABC29DEFGHIJKL (resp_len: 14)
<info> app: row: ABC28DEFGHIJKL; (resp_len: 14, usb buffer: 0)
<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 15
<info> app: m_rx_buffer: ;ABC30DEFGHIJKL
<info> app: resp: ABC30DEFGHIJKL (resp_len: 14)

<info> app: app_usbd_cdc_acm_read_any()
<info> app: NRF_SUCCESS: rx_size = 1
<info> app: m_rx_buffer: M
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): USB_TXRX_STATE_RX
<info> app: APP_USBD_CDC_ACM_USER_EVT_PORT_CLOSE
<info> app: cdc_acm_user_ev_handler(): APP_USBD_CDC_ACM_USER_EVT<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()
<info> app: app_usbd_cdc_acm_read_any(): other 8
<info> app: app_usbd_cdc_acm_read_any()


// Breakpoint hit

Modified usb.c::usb_read_buf():
// The changes a bit higher is also just a commented out NRF_LOG_FLUSH().

Modified main.c:

Here is my test setup:

Device side:

devzone.nordicsemi.com/.../usb_2D00_test_2D00_packed_2D00_2_2D00_hieu_2D00_231204.zip

Host PC side, including logs:

devzone.nordicsemi.com/.../c315710_5F00_python_5F00_script.zip

Once again, my apology for having been unable to help.

Best regards,

Hieu

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

PeterLjung — Fri, 17 Nov 2023 10:55:17 GMT

Ok no problem. I think it would be good if you could try to reproduce on a Linux machine if possible.

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

Hieu — Fri, 17 Nov 2023 08:54:40 GMT

Hi Peter,

Just letting you know I am still on this case. We have been in a shorthanded situation, and it's been difficult for me to allocate the amount of time this case deserves.

I am sorry for the inconvenience. I will try to get to it as soon as I could.

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

PeterLjung — Wed, 08 Nov 2023 12:35:34 GMT

Ok, yes I tried both to comment out all logging in usb.c i.e. in all eventhandlers and also tried to disable in sdk_config (NRF_LOG_ENABLED = 0), but it seems to behave as before.

When I run this on Ubuntu 20.04 the "working_sample" continues i.e. transmission completes with multiple transmissions. While "not_working_sample" does not.

This is the code I used in this test.
usb-test-packed-4.tgz

I also tried to detect USB device on a newly installed WIndows 10 Home machine, but that behaves like the previous one. I got a short flash something like "Detected new USB device USB CDC PALOS", but it is not detected in Device Manager. On a collegues Windows it works though. I don't know why this differ.

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

Hieu — Wed, 08 Nov 2023 11:43:55 GMT

Another engineer took a quick look and pointed out that you are having NRF_LOG_FLUSH() in the USB event handler, which would cause delay in interrupt execution, potentially caused timing issues.

Could you please disable logging entirely and run a test?

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

PeterLjung — Tue, 07 Nov 2023 08:27:29 GMT

Yes, you are correct. Serial port on windows start from 0 which correspond to COM1.

So to fix that this row could be changed.

sp = SerialPort.new(serial_dev.to_i - 1, 115200, 8, 1, SerialPort::NONE)

I looks like at least 2 rows are transmitted in your current windows run. Doesn't go further than that?

The issue I see on Linux is just at the end of the transmission. And the issue will be seen as wrong (old) data is received from USB internal buffer. If all rows are transmitted correctly the loop should just continue with another transmission from script after 5 seconds.

If you want to keep the row handling of the firmware i.e. splitting rows delimited by ; maybe you only replace current content examples by to possibly simplify debugging.

def working_sample
return "ABC00DEFGHIJKLMNOP;ABC01DEFGHIJKLMNOPQR;ABC02DEFGHIJKLMNOPQR;ABC03DEFGHIJKLMNOPQR;ABC04DEFGHIJKLMNOPQR;ABC05DEFGHIJKLMNOPQR;ABC06DEFGHIJKLMNOP;ABC07DEFGHIJKLMNOPQR;ABC08DEFGHIJKLMNOPQR;ABC09DEFGHIJKLMNOPQR;ABC10DEFGHIJKLMNOPQR;ABC11DEFGHIJKLMNOP;ABC12DEFGHIJKLMNOPQR;ABC13DEFGHIJKLMNOPQR;ABC14DEFGHIJKLMNOPQR;ABC15DEFGHIJKLMNOP;ABC16DEFGHIJKLMNOPQR;ABC17DEFGHIJKLMNOPQR;ABC18DEFGHIJKLMNOPQR;ABC19DEFGHIJKLMNOP;ABC20DEFGHIJKLMNOP;ABC21DEFGHIJKLMNOP;ABC22DEFGHIJKLMNOP;ABC23DEFGHIJKLMNOP;ABC24DEFGHIJKL;ABC26DEFGHIJKL;ABC27DEFGHIJKL;ABC28DEFGHIJKL;ABC29DEFGHIJKL;ABC30DEFGHIJKLM;ABC31DEFGHIJKLM;EOT;"
end

def not_working_sample
return "ABC00DEFGHIJKLMNOP;ABC01DEFGHIJKLMNOPQR;ABC02DEFGHIJKLMNOPQR;ABC03DEFGHIJKLMNOPQR;ABC04DEFGHIJKLMNOPQR;ABC05DEFGHIJKLMNOPQR;ABC06DEFGHIJKLMNOP;ABC07DEFGHIJKLMNOPQR;ABC08DEFGHIJKLMNOPQR;ABC09DEFGHIJKLMNOPQR;ABC10DEFGHIJKLMNOPQR;ABC11DEFGHIJKLMNOP;ABC12DEFGHIJKLMNOPQR;ABC13DEFGHIJKLMNOPQR;ABC14DEFGHIJKLMNOPQR;ABC15DEFGHIJKLMNOP;ABC16DEFGHIJKLMNOPQR;ABC17DEFGHIJKLMNOPQR;ABC18DEFGHIJKLMNOPQR;ABC19DEFGHIJKLMNOP;ABC20DEFGHIJKLMNOP;ABC21DEFGHIJKLMNOP;ABC22DEFGHIJKLMNOP;ABC23DEFGHIJKLMNOP;ABC24DEFGHIJKL;ABC26DEFGHIJKL;ABC27DEFGHIJKL;ABC28DEFGHIJKL;ABC29DEFGHIJKL;ABC30DEFGHIJKLM;EOT;"
end

I will also try to reproduce the same issue on Windows later this week.

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

Hieu — Mon, 06 Nov 2023 22:13:21 GMT

Hi Peter,

I see that you updated your reply today with further information on how to run it on Windows. Thank you so much for the help.

It seems it has an interesting bug where the real port it runs is always 1 number higher than the port given in argument. I.e., below I connect to COM30 by running ruby .\usb-test.rb 29.

Nonetheless, I tried that, and it seems I can produce some issue... The receiving logs showed a lot of data was missing. That probably was not the one you are describing?

I am not very successful with the Linux virtual machine attempt either. It seems the Ruby script cannot communicate with the device for some reason.

My Linux colleague can't go to office, unlike I had hoped.

If push comes to shove, I think I can cook up something on Python to replicate what your Ruby script should do.

This issue happens when the PC sends a specific length message to the nRF device, right?

The way I usually attempt to reproduce this kind of issues, I usually setup the TX device to send at a button trigger. In this case, I think I will just setup something simple like when I hit Space, the PC should send "ABCDEFGH00ABCDEFGH01ABCDEFGH02...ABCDEFGH56."

On the device end, I can try with either your code or a minimally modified CDC ACM example to use the _read_any() API, then slowly add/remove debug logs, depends on the details.

Do you think a setup like above would work?

I will also consider asking if someone from another team can give me a hand with the Linux trial.

Best regards,

Hieu

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

PeterLjung — Mon, 06 Nov 2023 15:15:42 GMT

I did a test on another Windows machine and there USB is detected fine. The one I am using does not work. But I also noticed that serial ports COM ports are rather written as a number rather than a device name as in Linux.
Also I cannot detect if device is connected on Windows which was discussed above. So the RW protocol does not work on Windows.
I made a quick rewrite that possibly could work on Windows. Device is not detected and script is will not be waiting for a command from the nRF device. I will not be able to test this until later this week (I dont have access to this machine) so it may very well have issues.
usb-test-packed-3-windows.tgz

So it is certainly much easier to try on regular Linux machine.

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

Hieu — Thu, 02 Nov 2023 10:03:32 GMT

There is one person in my team with a Linux machine, but they are away until next Monday. I will try to get their help then. In the meantime, I will try with a virtual machine.

Best regards,

Hieu

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

PeterLjung — Thu, 02 Nov 2023 09:26:37 GMT

I tried Nordic USB CDC ACM sample on another Windows machine and there it is detected fine.
But on the computer that I have access to it doesn't for some reason. The device is not detected at all.

1. I looked at BIOS settings to see if devices was disabled
2. I tested another device (USB stick) on the same port to see if that worked. And yes.
3. I tried to install nRF utils tools to see if there still was some driver issue.
4. I tried to power the board through debug USB port to see if power was the issue.

But it works fine on 3 other machines with different OSes (macOS, OpenBSD and Linux).
Windows is just too strange. If you could try on Linux it would be great.

Best regards / Peter

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

Hieu — Wed, 01 Nov 2023 22:19:07 GMT

Hi Peter,

I would like to give you an update.

I tried Windows again with your suggestion here:

[quote user="PeterLjung"]I think we had to introduce a delay specifically for Windows compared with Linux in another project.
So you could try to introduce a delay between usb_config() and usb_write() and/or include a set of process_usb_events() between operations.[/quote]

But the result has remained the same.

I also tried to create another setup with WSL. However, I have been having issue passing the USB port to WSL. It seems there are some firewall issues.

I will try to pull in some other help, preferably someone who is working with Linux.

Best regards,

Hieu

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

Hieu — Mon, 30 Oct 2023 08:20:50 GMT

Not recently, but I have worked with the Nordic USB CDC sample on my Windows machine before. The driver should be automatically installed after a few seconds. Could it be that your Windows machine's driver installation is limited due to enterprise firewall or Windows policy?

I haven't been successful yet. I will try WSL next, not having a Linux machine to try,

Best regards,

Hieu

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

PeterLjung — Fri, 27 Oct 2023 13:20:14 GMT

I tried this on a Windows machine ...

But unfortunately I couldn't get Nordic USB CDC ACM sample to work on Windows or my sample.

Device was not detected by Device Manager.

USB CDC ACM Example

I also tried on Linux and there both variants was detected by the OS.

I tested on a Windows 10 machine and assume that no drivers are needed.
If you could test on a Linux machine I think it would simplify things, but I will also make a new attempt on Windows next week.

Have you tested the Nordic USB CDC sample on your machine?

Best regards / Peter

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

PeterLjung — Thu, 26 Oct 2023 14:22:03 GMT

Actually I have not tried exactly this sample on Windows.
Question is if the USB device is detected by Windows or not. Can you check?

On Linux, device may alter between e.g. two devices e.g. ttyACM2 and ttyACM3.

I think we had to introduce a delay specifically for Windows compared with Linux in another project.
So you could try to introduce a delay between usb_config() and usb_write() and/or include a set of process_usb_events() between operations.

Hope this helps.

I will also try on a Windows machine tomorrow and compare ...

Best regards / Peter

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

Hieu — Thu, 26 Oct 2023 13:03:00 GMT

Thanks for the tip, Peter. I commented out the USB connected check and it seems the script can progress past that now.

However, it seems the test is not running as expected:

When I tried the first project you sent instead, my PC doesn't even accept the USB device..

Do you have any idea what is wrong? I will dive into it in a bit, but asking in case something makes sense for you immediately.

By the way, I am thinking about modifying the projects so that the device just listens, and the Ruby script immediately sends a fixed size packet. Do you think there is any problem with this?

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

PeterLjung — Thu, 26 Oct 2023 10:45:17 GMT

Aha, so you are on a Windows machine?

lsusb is UNIX utility so that could be a problem on Windows.
I am working from Ubuntu 20.04.

lsusb and usb_connected? part is only for robustness of the script and could be removed if neccesary.

# Open protocol towards serial client
loop do
if usb_connected? then
show "BLE device connected. Connect to USB serial port."
sp = SerialPort.new(serial_dev, 115200, 8, 1, SerialPort::NONE)
break
else
show "BLE device not connected to USB port. Wait ..."
sleep 10
end
end

could be replaced by

sp = SerialPort.new(serial_dev, 115200, 8, 1, SerialPort::NONE)

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

PeterLjung — Thu, 26 Oct 2023 09:37:10 GMT

[deleted]

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

Hieu — Wed, 25 Oct 2023 22:20:58 GMT

[quote user="PeterLjung"]It looks like disabling event queue (APP_USBD_CONFIG_EVENT_QUEUE_ENABLE) removes manual triggering of usb state via app_usbd_event_queue_process() so it changes the usage of the API a bit.[/quote]

That's right. If I remember correctly, you probably won't need app_usbd_event_queue_process() when the event queue is disabled. This is just a temporary debugging change to help narrow down the issue though.

[quote user="PeterLjung"]We tried app_usbd_cdc_acm_read(), but ended up using _any() variant instead. It think we had the same problem with this one. Is really double buffering usb stack implementation simpler?[/quote]

I don't think either _read() or _read_any() API implementation in the app_usbd library is significantly simpler than the other.

Or could you perhaps be asking about the application layer, where you implement the handling? If so, I think the implementation is different, but not necessarily simpler or more complex. I just suggested it in case it could be a working alternative for you, as well as a potential further hint on where the issue.

However, that's a bit strange if you had the same issue with the _read() API. The way the two APIs handle buffers are different, after all.
Could you check if there are some notes, such as in commit messages, from that time?

[quote user="PeterLjung"]Regarding ruby it should only be to install ruby and one single gem serialport.
Make sure it looks something like this. Later ruby version should also be fine.[/quote]

Ah yes. I have Ruby 3.2.2 and serialport gem version 1.3.2. The hiccups I mentioned was embarrassingly with the installation... Turns out I had some misunderstanding about the MSYS2 part of the installation log, and everything went (almost) fine...

However, when I run the script, it is not working though.

There were a couple of error message during installation about the wizard being unable to find catgets and libcatgets for removal to avoid conflicts.
Seems related to this PR. I don't think this is an issue though.

I will try and see if this is just some simple differences in COM port handling between Windows and Linux and fix it. If that doesn't work, I will figure something else out. I will keep you posted, nonetheless.

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

PeterLjung — Wed, 25 Oct 2023 07:54:27 GMT

It looks like disabling event queue (APP_USBD_CONFIG_EVENT_QUEUE_ENABLE) removes manual triggering of usb state via app_usbd_event_queue_process() so it changes the usage of the API a bit.

We tried app_usbd_cdc_acm_read(), but ended up using _any() variant instead. It think we had the same problem with this one. Is really double buffering usb stack implementation simpler?

We are using a separate sw stack that only support SDK so right now its not possible to move to connect.

Regarding ruby it should only be to install ruby and one single gem serialport.
Make sure it looks something like this. Later ruby version should also be fine.

$ ruby -v
ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux-gnu]

$ gem list

*** LOCAL GEMS ***

...
serialport (1.3.2)
...

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

Hieu — Tue, 24 Oct 2023 18:18:10 GMT

Hi Peter,

I would like to give a short reply. I returned and started working on the case. However, I am unfamiliar with Ruby and have been having some hiccups with the reproduction.

[quote user="PeterLjung"]"You could test the application in IRQ mode, with the event queue disabled to see if that changes anything."

Should IRQ be disabled at some state of the program?[/quote]

This is done by setting APP_USBD_CONFIG_EVENT_QUEUE_ENABLE to 0. This disables the USB event queue in the app_usbd library and all USB events would be handled directly in the interrupt handler.

I would like to discuss an alternative while the issue is not yet clear. Have you tried using app_usbd_cdc_acm_read() instead? That API allows double buffering. Since the package length is not constant, you probably have to use a buffer size of 1. However, if your package has a format, or if you can control the host side to send it in a divisible number, like 512, 528, 544, ... (increment by 16), then you can use a larger buffer size.

One more thing I should have checked in my first reply. Are you working on a new product? What development stage are you at? If you are at early stages, then our official recommendation is the nRF Connect SDK instead of the nRF5 SDK, which is in maintenance mode.

I will continue to investigate this issue today and tomorrow. I would like to at least get to the point of getting a reproduction setup to run.

Best regards,

Hieu

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

PeterLjung — Mon, 23 Oct 2023 15:25:01 GMT

Yes, app_usbd_event_queue_process() is only called in main() in test app above and not from any interrupt routine.

I also tried to replace blocking nrf_delay_ms() calls with RTC based events, but the same behavior persists.

Not exactly sure what you mean by this:
"You could test the application in IRQ mode, with the event queue disabled to see if that changes anything."

Should IRQ be disabled at some state of the program?

Anyway I have attached my updated version here. Only modified main.c
usb-test-packed-2.tgz

Best regards / Peter

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

Simonr — Mon, 23 Oct 2023 12:54:16 GMT

Hieu will be back in office to continue this case tomorrow, but in the meantime one of our experts on the USB stack has taken a look at your project and has some feedback for you.

Although we couldn't pinpoint what the error is likely to be we have some suggestions to what it could be.

First off, do you do the intermediate call to while (app_usbd_event_queue_process() from an interrupt? If so that will definitely cause trouble with the priorities in your application. You could test the application in IRQ mode, with the event queue disabled to see if that changes anything.

There might be a problem with the way you're using the app_usbd_event_queue_process() function, asthe point is to call it in your while loop, and not wherever you think it "fits" into your application.

You're also using multiple blocking delays within your project, and the entire nRF5 SDK is based on asynchronous APIs, with callbacks when there is data to process. We would recommend you set up your project similarly, and go to a sleep mode at the end of your while loop instead of just running a delay. Based on the number of iterations we've had of our USB stack in the nRF5 SDK we don't think this is inherently an issue within the stack.

Best regards,

Simon

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

Susheel Nuguru — Sun, 22 Oct 2023 07:30:03 GMT

Hi Peter,

This seems to be some thing in the design of the state machine.I haven't been able to replicate it yet as both of the working and non_working seems be stuck at my end. I am running ubuntu in the virtual machine but running VM should not be an issue.

I will try to see if I can include the developer into helping us into this issue.

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

PeterLjung — Thu, 19 Oct 2023 09:30:24 GMT

Size is accessed both directly after app_usbd_cdc_acm_read_any() on success.
And from event handler in pending response.

The following is a complete example including firmware and a small Ruby script on PC side to reproduce the error.
That should hopefully make it clear how we are using the API.
usb-test-packed-no-sdk.tgz

See README.md for intro of how to use the code.

Regards

RE: USB CDC ACM: RX data gets overwritten in app_usbd_cdc_acm_read_any() at end of data transmission

Hieu — Wed, 18 Oct 2023 22:11:49 GMT

Hi Peter,

Firstly, I would like to update you that I have been looking into the USB CDC ACM modules and a reproduction setup base on the USB CDC ACM example.

Next, I would like to ask about a few details in your code:

[quote user=""]ret = app_usbd_cdc_acm_read_any(&m_app_cdc_acm, m_rx_buffer, MIN(BUFFER_SIZE,size));[/quote]

How are you calling this function?

[quote user=""]rx_size = app_usbd_cdc_acm_rx_size(p_cdc_acm);
copy_rx_data(buffer, n, m_rx_buffer);[/quote]

Are buffer and n variables for another level of buffer where you just recombine the fragments of data from received in m_rx_buffer across multiple the app_usbd_cdc_acm_read_any() calls?

If that's not correct, could you give more details about them?

Also, it would be great if you can recommend me a terminal program that goes well with this kind of test. I have been using PuTTy but I don't feel very confident that it's suitable for sending a large number of bytes at once.

Finally, I understand that you have waited a long time before receiving the first reply. However, I am out of office for the rest of the week. I will try to follow up if possible. My apology for the inconvenience.

Regards,

Hieu