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 

I will try to prepare these files by tomorrow, but I would also recommend getting an nRF52840DK if fixing this issue is important. 

Then it is much easier to flash (and potentially debug) the chip in order to investigate the issue. 

Best regards
Torbjørn

[ovrebekk]

Hi

On second thought it is a bit hard for me to generate the zip file for you, since I don't know what kind of DFU settings you are using, what application version you are using now and so on. 

You should be able to generate a zip file with a SoftDevice and application using the following nrfutil command:

nrfutil.exe pkg generate --sd-req 0xFFFE --sd-id 0xFFFE --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

Best regards
Torbjørn

[A.St.]

Generating the .zip with command

> nrfutil pkg generate --sd-req 0xFFFE --sd-id 0xFFFE --hw-version 52 --application-version 1 --application ble_connectivity_s140_usb_hci_pca10059.hex --softdevice s140_nrf52_7.2.0_softdevice.hex app_plus_sd.zip

but when we try to flash the dongle we get

>nrfutil dfu usb-serial -pkg /input/app_plus_sd.zip -p /dev/ttyACM0
[------------------------------------] 0%

...

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.

Ill guess that the problem is api 7.2.0 because our nrfutil is version 6.1.3 which only supports up to s140_nrf52_7.0.1. We already tried to update nrfutil via

python3 -m pip install -U pip

python3 -m pip install nrfutil

But it tells us that nrfutil is already the latest version. Building nrfutil from scratch is currently not an option for us. Also getting a nRF52840DK is not really an option for us right now, because it would be a huge bureaucratic effort to get one.

[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