• State Verified Answer
  • Replies 8 replies
  • Subscribers 95 subscribers
  • Views 3192 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 297400
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

USBD_STATUS_CANCELED

JoEi

Hi there,

as already mentioned in other tickets I'm developing a usb to uart bridge based on the nrf52820. The nRF5 SDK version I'm using is 17.1.0.

Right now I'm facing an error on the usb side.

A bit of a context:
When connected, one of our test tools retrieves information (e.g. device state, device id, ...) from a device. This is done every second by sending 4 messages to it.
If it takes one answer more than 10 seconds to return, the connection to the device is closed.

Right now I'm facing the problem that after some time (20 seconds up to 10 minutes) one answer isn't completely received.
Most of the time the answer get's split into 2 parts (according to wireshark). The first part is always received. When the error happens the second part only gets transmitted when the connection get's closed. When this happens the IRP USB_STATE is USBD_STATUS_CANCELED (0xc0010000).

In the image you can see that packet number 13124 is the request and packets number 13127 and 13150 are the answer.

Any idea what could be causing this?

Kind regards,
Johannes

Parents
  • 0

    Hi,

     

    Q1: Could you share the .pcapng?

    Right now I'm facing the problem that after some time (20 seconds up to 10 minutes) one answer isn't completely received.
    Most of the time the answer get's split into 2 parts (according to wireshark). The first part is always received. When the error happens the second part only gets transmitted when the connection get's closed. When this happens the IRP USB_STATE is USBD_STATUS_CANCELED (0xc0010000).

    Q2: any logs from the nRF side that could hint at what is happening?

    Q3: How does your schematic look wrt. D+/D- routing? There should not be any series-resistors on these lines (as a side-note: but we do recommend to use ESD protection diodes).

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Hi Håkon,

    A1: Yeah sure. The interface in question is interface number 1.failed_communication_-_USBD_STATUS_CANCELED.pcapng

    A2: Sadly no. I've tried activating the logs in all USB modules but nothing happened.

    A3: The only thing between the usb port and the nRF D+/D- pins is a USBLC6-2SC6 diode.

    Kind regards,
    Johannes

Reply Children
  • 0 in reply to JoEi

    Hi Johannes,

     

    Schematic looks good.

    The sniffer trace unfortunately is on a OS level, and does not show much other than the communication stops on EP1 (ie. your data EP)

     

    JoEi said:

    Sadly no. I've tried activating the logs in all USB modules but nothing happened.

    Did you set sdk_config.h:NRFX_USBD_CONFIG_LOG_ENABLED in addition to sdk_config.h:NRF_LOG_ENABLED?

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Hi Håkon,

    sorry for the late reply I've been on vacation the last few days.

    Håkon Alseth said:
    Did you set sdk_config.h:NRFX_USBD_CONFIG_LOG_ENABLED in addition to sdk_config.h:NRF_LOG_ENABLED?

    Yes I did.

    I'm wondering why the missing data get's "received" when the program closes the connection to the device. Is there some sort of flush being performed?

    What happens if I try to send more than 64 byte at once and when will I receive TX finished in this case?

    Kind regards,
    Johannes

  • 0 in reply to JoEi

    Hi,

     

    JoEi said:
    I'm wondering why the missing data get's "received" when the program closes the connection to the device. Is there some sort of flush being performed?

    USB is, like most other transports, driven by a host. If the host stops polling the device, incoming data stream also stops.

    Not saying that this happens here, but it might be a possibility.

     

    JoEi said:

    What happens if I try to send more than 64 byte at once and when will I receive TX finished in this case?

    On the bus itself, it will be split up into 64 byte chunks.

    If you continuously send a size that is equal to the EP side, it might be beneficial to look at sdk_config.h::USBD_CONFIG_ISO_IN_ZLP.

    Also, what terminal are you using when you're seeing this issue? Is it present on all computers, with different terminal programs?

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Hi Håkon,

    I'm using a usbd class I specifically developed for our product and not the cdc_acm class. It has 2 bulk interfaces, one for debugging messages and one for control messages and file transfer.

    So far I've seen it on 3-4 different PCs.
    I've seen this issue when working with our dev studio and it's testbed.
    When being connected to the testbed every second some status information is retrieved from the device.

    I've added some debug messages before calling my usb_send function to get the amount of data I'm trying to transmit. I've noticed that the error happens when the length of the last chunk of data I'm trying to transmit is a multiple of 64.

    Kind regards,
    Johannes

  • 0 in reply to JoEi

    Hi,

     

    Sorry, my former suggestion was the wrong config setting.
    It should be sdk_config.h::APP_USBD_CDC_ACM_ZLP_ON_EPSIZE_WRITE, not the USBD_CONFIG_ISO_IN_ZLP.

     

    This is set to '1' by default, and when sending binary data, it could be beneficial to have this set to '0'.

     

    Kind regards,

    Håkon

Related
Terms of service