Problem with USB CDC Data Transfer

RE: Problem with USB CDC Data Transfer

Håkon Alseth — Wed, 06 Nov 2019 09:34:47 GMT

I placed it just before entering the loop. The important part is to set it before you enumerate, usually in the init will be fine.

Here's a quick LE to BE 32 unsigned macro, so that your baud is read out correct on the host side:

#define LE_TO_BE32(x) \
        (x >>24 & 0xff) |   \
        ((x<<8)&0xff0000) | \
        ((x>>8)&0xff00) | \
        ((x<<24)&0xff000000)

    const uint32_t baud_rate = LE_TO_BE32 (115200);

You can ofcourse set this to whatever baud you'd like (without it having an effect on the USB throughput), its really only meant as a "meta data" if you actually communicate with an external device using UART.

Do you get the correct baud settings now?

Kind regards,

Håkon

RE: Problem with USB CDC Data Transfer

jemiaha — Tue, 05 Nov 2019 17:31:35 GMT

Thanks!. I'm exploring that. It has an effect and I do see some strange values in the sniffer. Right now, in the USB setup there is the following code:

app_usbd_class_inst_t const * class_cdc_acm = app_usbd_cdc_acm_class_inst_get(&m_app_cdc_acm);
ret = app_usbd_class_append(class_cdc_acm);
APP_ERROR_CHECK(ret);

Where should the memcpy go in relation to that? (Before or after?)
Thanks

RE: Problem with USB CDC Data Transfer

Håkon Alseth — Tue, 05 Nov 2019 10:25:02 GMT

[quote user="jemiaha"]With the usbd_ble_uart example, to remove possible sources of the problem, I've removed/disabled the soft device and re-compiled it with ORIGIN = 0x0. The BT part is disabled but the USB CDC part is still testable.[/quote]

Why not test directly with usbd_cdc_acm? If you remove all the handling wrt. BLE in that sample, you're ending essentially up with the same functionality as in that sample, just that you also need to handle the logic around the USBD events so that they do not go through the SoftDevice anymore.

[quote user="jemiaha"]So far, the only difference I can detect between a good connection and a bad connection is that with a good connection the virtual comm port connection parameters are already setup. That why I was looking for a way to preset them from the nRF SDK side at compile time. So far as I can tell, there isn't a way to do this. Do you know of a way?[/quote]

There's no function for setting this explicitly, but you can do this in main:

    const uint32_t baud_rate = 115200;
    app_usbd_cdc_line_coding_t line_coding = 
    {
      .dwDTERate = &baud_rate,
      .bCharFormat = APP_USBD_CDC_LINE_STOPBIT_1,
      .bParityType = APP_USBD_CDC_LINE_PARITY_NONE,
      .bDataBits = 8,
    };
    memcpy(&m_app_cdc_acm.specific.p_data->ctx.line_coding, &line_coding, sizeof(app_usbd_cdc_line_coding_t));

I am a bit unsure about the endianess on the dwDTERate member, you might have to swap the bytes if you see some weird values in that field.

Kind regards,

Håkon

RE: Problem with USB CDC Data Transfer

jemiaha — Fri, 01 Nov 2019 15:26:26 GMT

Hi Håkon,

I've been doing all my testing on the PCA10056 DK while waiting for the customer's custom board to be completed. I'm using the usbd_ble_uart and peripheral/cli examples. The issue is observable with the usbd_ble_uart example with no modifications by watching the DK LEDs. With the peripheral/cli example I made a small modification that toggled a DK LED every time a byte was received. With the usbd_ble_uart example, to remove possible sources of the problem, I've removed/disabled the soft device and re-compiled it with ORIGIN = 0x0. The BT part is disabled but the USB CDC part is still testable.

The two examples setup the USB CDC UART differently but both suffer from the same issue. We're continuing to dig into the SW libraries used on the Windows10 side to see if there is some kind of negative interaction between the serial port libraries and the Virtual com-port setup.

So far, the only difference I can detect between a good connection and a bad connection is that with a good connection the virtual comm port connection parameters are already setup. That why I was looking for a way to preset them from the nRF SDK side at compile time. So far as I can tell, there isn't a way to do this. Do you know of a way?

Thanks

RE: Problem with USB CDC Data Transfer

Håkon Alseth — Thu, 31 Oct 2019 09:54:05 GMT

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

RE: Problem with USB CDC Data Transfer

jemiaha — Tue, 29 Oct 2019 20:51:25 GMT

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.

RE: Problem with USB CDC Data Transfer

jemiaha — Tue, 29 Oct 2019 17:04:40 GMT

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

RE: Problem with USB CDC Data Transfer

jemiaha — Tue, 29 Oct 2019 15:40:54 GMT

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

RE: Problem with USB CDC Data Transfer

Håkon Alseth — Tue, 29 Oct 2019 14:14:28 GMT

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