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

[A.St.]

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 anything we can do in the bootloader/softdevice/app to somehow fix this problem, so that no external usb-hub is needed?

[ovrebekk]

Hi 

This is not an known issue, but we haven't done any testing on this platform either. I assume you don't have this issue on a regular PC platform?

Do you have any means to sniff the USB communication between the dongle and the Nvidia host, so you can see what is going on?

Best regards
Torbjørn

[A.St.]

Hi Torbjørn,

we've send you a PM regarding USB sniffing.

We also posted this problem on the nvidia forums, where they asked if the device (the dongle) has a USB compliance test, see https://developer.nvidia.com/embedded/dlc/agx-xavier-3-1-compliance-test-guide

Has it?

[ovrebekk]

Hi 

This error means that the SoftDevice currently in the dongle is not corresponding to the one provided in the --sd-req parameter, which indicates it is not the S140 v6.1.0 that is on the dongle currently.

Is there any chance some other SoftDevice version could be on the dongle? 

On second thought, a different way to flash the connectivity software is to simply press the button on the dongle to put it in bootloader mode, and use the nRFConnect for Desktop Bluetooth application to program the connectivity firmware. 

This application will ask you if you want to flash the connected dongle, if you select it from the list of connected devices in the application. 

Could you try this out and see if it works better?

Best regards
Torbjørn

[A.St.]

Sorry for the delay but i just now had found time to address this.

Downloaded the nrfConnect for Desktop 3.9.0, updated the BLE application to 3.0.0 and flashed it to the dongle. I then also could scan for BT devices so this worked.

Unfortunately the error is still the same when plugging into the nvidia Xavier board, where we also updated the kernel to 4.9.253 in the meantime.

[ovrebekk]

Hi

No worries. Any chance you have considered my suggestion of getting an nRF52840DK? 

I think it will be easier to investigate this with access to logging and a debugger. 

Best regards
Torbjørn

[A.St.]

Will try to get one. Do we need more things then (e.g. special jtag) or only the DK board?

I also have a dongle with a pin-header (10 pins) soldered to the bottom of it. But no idea if this helps or how to interface with it. Would this be okay too?

[ovrebekk]

Hi

A.St. said:

Do we need more things then (e.g. special jtag) or only the DK board?

With the DK you don't need any extras, as it comes with a built in debugger. For this reason it is very useful for development purposes. You can also use the DK to program external boards (such as your dongle), as long as the board supply voltage is similar. 

A.St. said:

I also have a dongle with a pin-header (10 pins) soldered to the bottom of it. But no idea if this helps or how to interface with it. Would this be okay too?

If you have an external debugger you can use the 10-pin connector, yes, in order to program and debug the dongle directly. Still, a DK has some features that the dongle doesn't, such as an easier way to output log data, easier access to GPIO, and more buttons/LED's available. 

Best regards
Torbjørn

[A.St.]

We now have a nRF52840dk we will check it out when there is time.

Is there some getting started guide?

What should we do to debug this problem and how?

[ovrebekk]

Hi 

The nRF52840DK user guide is available here.

I think the first thing to test could be to run the cdc_acm example on the nRF52840DK with UART logging enabled (available through the virtual comport that the DK sets up), and try to reproduce the issue that you see with your dongle. 

Please also try the connectivity firmware on the DK, and see if that works or not. 

Best regards
Torbjørn

[A.St.]

For our own custom use-case we were able to fix this problem by first applying power to the board/chips, and then reset the chips after some delay with a GPIO.

Nonetheless we finally got some time to start debugging.

we've downloaded the latest SDK (17.1.0), put the switches into the expected positions (power source: VDD; sw6: DEFAULT; Power: ON) copied the cdc_acm example (nRF5_SDK_17.1.0_ddde560/examples/peripheral/usbd_cdc_acm/hex/usbd_cdc_acm_pca10056.hex) into the mounted nrf filesystem where the device resets automatically afterwards. Then we connected to /dev/ttyACM0 via minicom with the given terminal settings (115k, 8n1, ...) and also to /dev/ttyACM1 after plugging in the nrfUSB connection.

on the ACM0 we get a uard_cli prompt:

uart_cli:~$

on the ACM1 we get some data when pressing button 1 and led 3 blinks when typing things in the host-minicom.

How can we now see the debug log when plugging in the nrf-usb connection?

[ovrebekk]

Hi 

Do you not get log data in the ACM0 terminal?

You should get something like this when running the example (in this case I first connect the USB, then send four characters through the USB CDC comport, and then I remove and reconnect the USB again):

If you want you can also redirect logging to another interface, such as RTT. Then you will not depend on the UART console for logging information, but can use the debug interface instead. To view the RTT log you need to use the J-Link RTT Viewer application, and enable RTT logging by setting NRF_LOG_BACKEND_RTT_ENABLED 1 in sdk_config.h, while setting NRF_CLI_LOG_BACKEND 0. 

Best regards
Torbjørn