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 

My bad. Apparently it is not possible to use the SD_REQ_ANY_VERSION (0xFFFE) value in release mode, so it is necessary to specify both the firmware version of the SoftDevice that is currently in the target, and the firmware version of the SoftDevice included in the update. 

The firmware version for any SoftDevice can be found in the release notes. 

For the S140 v6.1.0 it is 0x00AE

For the S140 v7.2.0 it is 0x0100

Then the command should look like this:

nrfutil.exe pkg generate --sd-req 0x00AE --sd-id 0x0100 --hw-version 52 --application-version X --application ble_connectivity_s140_usb_hci_pca10059.hex --softdevice s140_nrf52_7.2.0_softdevice.hex --key-file key_file.txt app_plus_sd.zip

Could you give this a go and see if it works better?

Best regards
Torbjørn

[A.St.]

With this command, we get the same error, maybe the traceback will help you:

Traceback (most recent call last):
  File "/usr/local/bin/nrfutil", line 8, in <module>
    sys.exit(cli())
  File "/usr/local/lib/python3.8/dist-packages/click/core.py", line 1128, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/click/core.py", line 1053, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.8/dist-packages/click/core.py", line 1659, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.8/dist-packages/click/core.py", line 1659, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.8/dist-packages/click/core.py", line 1395, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.8/dist-packages/click/core.py", line 754, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/nordicsemi/__main__.py", line 1022, in usb_serial
    do_serial(package, port, connect_delay, flow_control, packet_receipt_notification, baud_rate, serial_number, False,
  File "/usr/local/lib/python3.8/dist-packages/nordicsemi/__main__.py", line 978, in do_serial
    dfu.dfu_send_images()
  File "/usr/local/lib/python3.8/dist-packages/nordicsemi/dfu/dfu.py", line 119, in dfu_send_images
    self._dfu_send_image(self.manifest.softdevice)
  File "/usr/local/lib/python3.8/dist-packages/nordicsemi/dfu/dfu.py", line 95, in _dfu_send_image
    self.dfu_transport.send_init_packet(data)
  File "/usr/local/lib/python3.8/dist-packages/nordicsemi/dfu/dfu_transport_serial.py", line 256, in send_init_packet
    self.__execute()
  File "/usr/local/lib/python3.8/dist-packages/nordicsemi/dfu/dfu_transport_serial.py", line 421, in __execute
    self.__get_response(DfuTransportSerial.OP_CODE['Execute'])
  File "/usr/local/lib/python3.8/dist-packages/nordicsemi/dfu/dfu_transport_serial.py", line 502, in __get_response
    raise NordicSemiException('Extended Error 0x{:02X}: {}'.format(resp[3], data))
pc_ble_driver_py.exceptions.NordicSemiException: Extended Error 0x07: The array of supported SoftDevices for the update does not contain the FWID of the current SoftDevice.

[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?