Communication error "can't set config #1, error -32" (USB) when plugg-in Nordic nrf52840 dongle (PCA10059) into xavier

Hi,

as stated in the title, we have a nrf52840 dongle (PCA10059) which does not come up normally on a Nvidia xavier devboard. Output of dmesg:

[ 112.940331] usb 1-3.1: New USB device found, idVendor=1915, idProduct=c00a
[ 112.940335] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 112.940338] usb 1-3.1: Product: nRF52 Connectivity
[ 112.940341] usb 1-3.1: Manufacturer: Nordic Semiconductor
[ 112.940343] usb 1-3.1: SerialNumber: EE54BF5A789B
[ 112.948394] usb 1-3.1: can’t set config #1, error -32

We tried different OS and SW (bootloader/softdevice/application) versions all with the same outcome.

After a lot of testing and tracing we found out, that when we pull out the usb-dongle ot of the usb-socket just that far that the power-pins are still connected and only the connection-pins are disconnected and then plug it back, the device will be detected just fine. Also when using a external usb-hub it will come up normally.

So it seems the problem comes from a timing issue between the xavier-usb (tegra-xusb) driver and the dongle. Probably the dongle delivers the usb-config too slow so that the kernel has no config to select the further loading of cdc_acm.

Is there any kernel patch, to somehow fix this problem, so that no external usb-hub is needed?

Hi,
It looks to be an issue in signal quality. Does the device pass compliance test? The Xavier developer kit has done compliance test so it should be good for general devices.

If you use Xavier module + custom board, would need to do compliance test. There is a document:
https://developer.nvidia.com/embedded/dlc/agx-xavier-3-1-compliance-test-guide

Its not a Xavier module + custom board. It’s the official Xavier dev board, also the Dongle is not a custom board but a product sold by Nordic, see nRF52840 Dongle - nordicsemi.com

While playing with the linux kernel to find a reason, we found out that putting a delay at some place in the code will “fix” this problem.

Kernel patch:

Blockquote
diff -r -u kernel/kernel-4.9/drivers/usb/core/message.c xkernel/kernel-4.9/drivers/usb/core/message.c
— kernel/kernel-4.9/drivers/usb/core/message.c 2020-06-26 06:12:00.000000000 +0200
+++ xkernel/kernel-4.9/drivers/usb/core/message.c 2021-10-21 13:09:37.142332048 +0200
@@ -9,6 +9,7 @@
#include <linux/mm.h>
#include <linux/timer.h>
#include <linux/ctype.h>
+#include <linux/delay.h>
#include <linux/nls.h>
#include <linux/device.h>
#include <linux/scatterlist.h>
@@ -53,6 +54,7 @@
retval = usb_submit_urb(urb, GFP_NOIO);
if (unlikely(retval))
goto out;
+udelay(5000);
expire = timeout ? msecs_to_jiffies(timeout) : MAX_SCHEDULE_TIMEOUT;
if (!wait_for_completion_timeout(&ctx.done, expire)) {

So from what we observed, the “wait_for_completion_timeout” seems to return too quickly. We are no professional kernel hackers, would be interesting to see an official fix for this.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.