Problem with USB CDC Data Transfer

[jemiaha]

I'm experiencing a strange issue with the USB CDC example when connecting the nRF52840 to Windows 10.  This is with the 15.2 SDK. I'm using the usbd_ble_uart example on the BMD340 DK. When building the stock example and connecting the BMD-USB port to my PC the DK connects as a virtual comm port as expected. I can open it with a terminal emulator and see that data is being transferred. I'm using this example project to build software to connect to a custom application. If my custom application tries to talk to the DK BEFORE I test the connection with the terminal emulator then the custom application fails to be able to send data to the virtual comm port. Simply opening the port and then closing it with the terminal emulator puts the DK port in a "better" state and then the custom application is able to talk with the port.

It smelled like an OS issue so I fired up a serial port sniffer and see what was being sent by the different connection attempts. When the custom application tries to read the baud rate and data width from the virtual comm port BEFORE the terminal emulator has used the port it receives a baud rate of 0 and a data width of 0. Once the terminal emulator has opened and closed the connection and I re-sniff the session the baud rate is 9600 and the data with is 8 as expected. Please see the attached screen captures of side-by side comparisons of good and bad connections (Good on left, bad on right. First baud then data width): 

I've seen this issue on multiple PCs. I've also tried updating the windows USB CDC driver with the nordic_cdc_acm_examples.inf file. Somehow, for the initial connection, either the nRF5280's USB stack is in a strange state or the virtual comm port is in a weird state and it there can be no good connection until the terminal emulator makes a connection. Using the same port sniffing software I can see that the terminal emulator doesn't check the current values, it just writes the values it wants and moves forward.

So my questions are:
- If it's the nRF52's USB stack, is there a way to pre-set it so that it returns the correct baud rate and data with on the initial connection?
- If it's the virtual comm port, is there any way to set/reset it from the nRF52 side so that it's in the correct state for the initial connection?
Thanks

.

[Håkon Alseth]

Hi,

 

Virtual com-ports does not really care about the settings, as everything goes over to USB anyway on the transport side. You can open up the port with 300 baud, and send MBits/s given that the device handles it. What is the issue that you are observing? Is the data missing or corrupted?

Kind regards,

Håkon

[jemiaha]

Thanks for the response. The issue is that if I program the usbd_ble_uart example into the nRF52840, cycle its power, and open its virtual com-port with a terminal emulator first it works fine. When repeat those steps and try to open the port with my customer's application first the port is unable to send/receive data. If I open the port with a terminal emulator, close it, then open it with my customer's application, the port is able to send/receive data. 

In the screen shots I posted, you can see that the terminal emulator is heavy handed and writes the settings it wants as soon as it opens the port. My customer's application tries to read the port settings first. The values it gets are strange and it fails to be able to send/receive data. Once the terminal emulator has opened the port the values for baud and data width are normal and my customer's application can send/receive data. The customer's application is already released and cannot be updated. They're updating their hardware to use the nRF52840.

Virtual com-ports are usually very forgiving (unlike the old days of microcontroller USARTs right). This issue is strange in that I've never seen a virtual com-port have a bad "initial state" like this. I'm assuming there is some initial configuration on the nRF52840 side that's incorrect and it's getting modified by the terminal emulator connection that corrects it. Any ideas you have on what I could look for would be greatly appreciated.

Thanks

.

[jemiaha]

I should also add that I've used the customer's application to connect to other USB serial devices without this problem. I've honestly never encountered a situation like this where a virtual com port could be opened but not transfer any data. 

Thanks

.

[jemiaha]

I've been able to look more closely at the log files from the sniffer software (Serial Port Monitor, Eltima). After comparing the logs from the terminal emulator and from a simple Python script I can see that the initial 0 values I for baud and data width seem to be normal. From what I gather it's normal for there to be multiple opens and closes of the port behind the scenes by the OS before it's actually opened for tx/rx.

The start of the issue is actually later in the log files. The nRF52840 gives no sign that a connection was made (APP_USBD_CDC_ACM_USER_EVT_PORT_OPEN) though the driver thinks it as made a connection. When the port is finally opened for writing the first call to IRP_MJ_WRITE registers as successfully when it actually wasn't (No RX shown by the nRF52840, APP_USBD_CDC_ACM_USER_EVT_RX_DONE). The second call to IRP_MJ_WRITE times-out with STATUS_TIMEOUT. All following write attempts of IRP_MJ_WRITE also fail but with STATUS_IO_TIMEOUT.

I'm still doing compares between good and bad logs to find more clues.

.

[Håkon Alseth]

Are you testing on a custom board? if yes; is there any components on the D+/D- lines that might cause this?

Are you able to reproduce this with a DK?

 

Kind regards,

Håkon