USBD_STATUS_CANCELED

RE: USBD_STATUS_CANCELED

JoEi — Mon, 07 Nov 2022 16:52:54 GMT

Hi Håkon,

I finally found a solution to my problem.

[quote userid="2115" url="~/f/nordic-q-a/93199/usbd_status_canceled/393874"]This is set to '1' by default, and when sending binary data, it could be beneficial to have this set to '0'.[/quote]

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

RE: USBD_STATUS_CANCELED

Håkon Alseth — Thu, 03 Nov 2022 12:55:23 GMT

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

RE: USBD_STATUS_CANCELED

JoEi — Wed, 02 Nov 2022 16:50:08 GMT

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

RE: USBD_STATUS_CANCELED

Håkon Alseth — Wed, 02 Nov 2022 14:27:59 GMT

Hi,

[quote user="Johannes"]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?[/quote]

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.

[quote user="Johannes"]

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

[/quote]

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

RE: USBD_STATUS_CANCELED

JoEi — Wed, 02 Nov 2022 12:32:10 GMT

Hi Håkon,

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

[quote userid="2115" url="~/f/nordic-q-a/93199/usbd_status_canceled/392628"]Did you set sdk_config.h:NRFX_USBD_CONFIG_LOG_ENABLED in addition to sdk_config.h:NRF_LOG_ENABLED?[/quote]

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

RE: USBD_STATUS_CANCELED

Håkon Alseth — Wed, 26 Oct 2022 12:56:30 GMT

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)

[quote user="Johannes"]

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

[/quote]

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

Kind regards,

Håkon

RE: USBD_STATUS_CANCELED

JoEi — Tue, 25 Oct 2022 13:13:52 GMT

Hi Håkon,

A1: Yeah sure. The interface in question is interface number 1.devzone.nordicsemi.com/.../failed_5F00_communication_5F002D005F00_USBD_5F00_STATUS_5F00_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

RE: USBD_STATUS_CANCELED

Håkon Alseth — Tue, 25 Oct 2022 12:08:56 GMT

Hi,

Q1: Could you share the .pcapng?

[quote user=""]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).[/quote]

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