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

[Håkon Alseth]

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

[JoEi]

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

[Håkon Alseth]

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

[JoEi]

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

[Håkon Alseth]

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

[JoEi]

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

[Håkon Alseth]

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

[JoEi]

Hi Håkon,

I finally found a solution to my problem.

Håkon Alseth said:

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

In my case it was exactly the other way round.

Additionally I had to change the way I'm processing the UART data.
Bit of a context:
The UART message has a header so that the bridge knows how the message is encoded and on which USB interface the data must be sent or if is a control message for the bridge itself.

Till now my UART_RxProcess function just took one byte at a time.
After analysing the header the data get's written into a buffer. When the buffer is full the data get's put into my TX FIFO.
Additionally a timer was started that would put the data of the buffer into the FIFO if the buffer wasn't completely filled and for 10ms no data was received.

Now I've moved the loop from uart_event_sched_handler into UART_RxProcess. Before returning from UART_RxProcess I'm putting the buffer into the FIFO so that I'm able to get rid of the timer.

Kind regards,
Johannes