Using nrfutil to program an off-the-shelf XIAO nRF52840 module

[cor10]

System Details:

• Chip: nRF52840, XIAO Module
• nRF5 SDK: Version 16.0.0
  
• mdk version: 8.46.0
• nrfjprog version: 10.15.4 external
• nrfutil version: 6.1.3

• JLinkARM.dll version: 7.64d

Hello,

I have tested an nRF SDK example application (usbd_generic_hids) on my nRF52840 DK board, and I now would like to try and flash this application onto my off-the-shelf XIAO nRF52840 modules. I have used nrfutil in the past in order to perform DFU, but it has always been for OTA DFU via BLE. I want to know how I can program just the application itself. I believe this usbd_generic_hids example does not require a SoftDevice to be present, and I am not sure if it needs a bootloader (I dont think so).

I havent programmed an off-the-shelf module like this before, so I have a few questions:

1. I know that the XIAO module comes with a USB bootloader built-in, and I was recommended to leave that bootloader intact for easier programming. However, as I said before, I am familiar with OTA DFU and secure dfu bootloaders on the nRF52840, so I should be able to program this device wirelessly and not have to worry about overwriting the default XIAO bootloader with a nRF-based bootloader. I would personally prefer to use our normal dfu secure bootloader, with softdevice, because this is more consistent with the other versions of this device that I have been developing. Is this possible? Is there anything I should be aware of in this process?
2. I have tried using nrfutil to generate a package of the application code by itself. It compiles and creates the .zip package just fine, but it fails to actually perform the DFU (error message included below). Is it even possible to do what I am trying? I feel like I need the dfu bootloader on-board in order to perform this usb-based dfu process.
   

   + nrfutil pkg generate --hw-version 52 --sd-req 0xCA --application-version 1 --application ../nrf-sdk/examples/peripheral/usbd_hid_generic/pca10056/blank/armgcc/_build/nrf52840_xxaa.hex usbd_hid.zip                         
                                                                                                                                                                                                                                  
   |===============================================================|                                                                                                                                                              
   |##      ##    ###    ########  ##    ## #### ##    ##  ######  |                                                                                                                                                              
   |##  ##  ##   ## ##   ##     ## ###   ##  ##  ###   ## ##    ## |                                                                                                                                                              
   |##  ##  ##  ##   ##  ##     ## ####  ##  ##  ####  ## ##       |                                                                                                                                                              
   |##  ##  ## ##     ## ########  ## ## ##  ##  ## ## ## ##   ####|                                                                                                                                                              
   |##  ##  ## ######### ##   ##   ##  ####  ##  ##  #### ##    ## |                                                                                                                                                              
   |##  ##  ## ##     ## ##    ##  ##   ###  ##  ##   ### ##    ## |                                                                                                                                                              
   | ###  ###  ##     ## ##     ## ##    ## #### ##    ##  ######  |                                                                                                                                                              
   |===============================================================|                                                                                                                                                              
   |You are not providing a signature key, which means the DFU     |                                                                                                                                                              
   |files will not be signed, and are vulnerable to tampering.     |                                               
   |This is only compatible with a signature-less bootloader and is|                                               
   |not suitable for production environments.                      |                                               
   |===============================================================|                                               
                                                                                                                   
   Zip created at usbd_hid.zip                                                                                     
   + nrfutil dfu usb-serial -pkg usbd_hid.zip -p /dev/cu.usbmodem14301 -b 115200                                   
     [------------------------------------]    0%                                                                  
   Traceback (most recent call last):                                                                              
     File "/usr/local/bin/nrfutil", line 8, in <module>                                                            
       sys.exit(cli())                                                                                             
     File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1128, in __call__                           
       return self.main(*args, **kwargs)                                                                           
     File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1053, in main                               
       rv = self.invoke(ctx)                                                                                       
     File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1659, in invoke                             
       return _process_result(sub_ctx.command.invoke(sub_ctx))                                                     
     File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1659, in invoke                             
       return _process_result(sub_ctx.command.invoke(sub_ctx))                                                     
     File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1395, in invoke                             
       return ctx.invoke(self.callback, **ctx.params)                                                              
     File "/usr/local/lib/python3.9/site-packages/click/core.py", line 754, in invoke                              
       return __callback(*args, **kwargs)                                                                          
     File "/usr/local/lib/python3.9/site-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.9/site-packages/nordicsemi/__main__.py", line 978, in do_serial                                                                                                                                 
       dfu.dfu_send_images()                               
     File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu.py", line 127, in dfu_send_images
       self._dfu_send_image(self.manifest.application)     
     File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu.py", line 88, in _dfu_send_image                                                                                                                             
       self.dfu_transport.open()                           
     File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 217, in open                                                                                                                      
       self.__get_mtu()                                                                                            
     File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 366, in __get_mtu                                                                                                                 
       self.mtu = struct.unpack('<H', bytearray(response))[0]                       
   TypeError: cannot convert 'NoneType' object to bytearray  

3. Any general advice on what resources will help me learn how to do this?

Thank you in advance :)

[mytzyiay]

According to https://wiki.seeedstudio.com/XIAO_BLE/ the manufacturer advises flashing this device through the Arduino GUI.  Are you sure their default bootloader implements a serial protocol compatible with nrfutil?

cor10 said:

However, as I said before, I am familiar with OTA DFU and secure dfu bootloaders on the nRF52840, so I should be able to program this device wirelessly and not have to worry about overwriting the default XIAO bootloader with a nRF-based bootloader

FWIW: I started off using nrfutil to program my nRF52840 Dongles through the Open Bootloader that it ships with.  This was sufficient for early prototyping and evaluation.  But when it came time to support OTA updates I wanted our own public key embedded into the bootloader so that it would only accept properly signed release images.  I also wanted to enforce a static partition map that won't change in future builds.  So I reflashed the dongles with a homebuilt mcuboot image through the SWD pins (just SWIO, SWCLK, GND).

[cor10]

Thanks for the quick response mytzyiay 

mytzyiay said:

Are you sure their default bootloader implements a serial protocol compatible with nrfutil?

Good question. No I am not sure.

I was recommended this specific module and the recommender also mentioned that I could use nrfutil to program it. I have taken their word on good faith, but I am not 100% sure that it is accurate. This is sort of why I came to this forum after running into issues.

I am familiar with the Arduino IDE, but have never used it to flash a separate application. I see in the docs that you linked that it is possible to get simple Arduino example code running on the board, but I wonder: Is it possible to flash my compiled nRF SDK application .hex/.bin file directly to the XIAO board via the Arduino IDE? Are there any resources out there where I could read more about this kind of thing? Is the first comment on this thread relevant?
or will I have to create an Arduino IDE-created version of my nRF52840 application from scratch? I hope there is an easier option than this...

mytzyiay said:

So I reflashed the dongles with a homebuilt mcuboot image through the SWD pins (just SWIO, SWCLK, GND).

I was also thinking this could be a realistic option, but wanted to see if there might be a software solution. Good to know its not too unreasonable to take this route if all else fails.

Thanks again for the help,

Corten

[mytzyiay]

cor10 said:

I was recommended this specific module and the recommender also mentioned that I could use nrfutil to program it.

If I'm looking at the correct repo, then it seems like the Arduino support package does use adafruit-nrfutil under the hood: https://github.com/zhanggw7/Seeed_52840_Core/blob/main/platform.txt

tools.nrfutil.upload.pattern="{cmd}" {upload.verbose} dfu serial -pkg "{build.path}/{build.project_name}.zip" -p {serial.port} -b 115200 --singlebank

Running in verbose mode (per  Is there a way to configure nrfutil to show all the bytes transmitted and received?  ) might help determine whether the bootloader is completely unresponsive / speaking the wrong protocol, or if a few commands are working and then it's getting wedged at one specific place.

mytzyiay said:

So I reflashed the dongles with a homebuilt mcuboot image through the SWD pins (just SWIO, SWCLK, GND).

I should probably add: in order to tell NCS that I was using a dongle without the default bootloader, I created a new board definition in my project tree.  So now I build with `west -b raw_dongle` rather than `west -b nrf52840dongle_nrf52840`

Maybe this works differently with the old nRF SDK; I have never used it.

[cor10]

mytzyiay said:

github.com/.../quote]

Nice find on the repo. Clearly they are using the nrfutil under the hood. So I updated my nrfutil dfu command with the verbose flags, and here is the output:

+ nrfutil pkg generate --hw-version 52 --sd-req 0xCA --application-version 1 --application ../nrf-sdk/examples/peripheral/usbd_hid_generic/pca10056/blank/armgcc/_build/nrf52840_xxaa.hex usbd_hid.zip     
     
|===============================================================|     
|##      ##    ###    ########  ##    ## #### ##    ##  ######  |     
|##  ##  ##   ## ##   ##     ## ###   ##  ##  ###   ## ##    ## |     
|##  ##  ##  ##   ##  ##     ## ####  ##  ##  ####  ## ##       |     
|##  ##  ## ##     ## ########  ## ## ##  ##  ## ## ## ##   ####|     
|##  ##  ## ######### ##   ##   ##  ####  ##  ##  #### ##    ## |-vers
|##  ##  ## ##     ## ##    ##  ##   ###  ##  ##   ### ##    ## |     
| ###  ###  ##     ## ##     ## ##    ## #### ##    ##  ######  |     
|===============================================================|r-ver
|You are not providing a signature key, which means the DFU     |     
|files will not be signed, and are vulnerable to tampering.     |     
|This is only compatible with a signature-less bootloader and is|     
|not suitable for production environments.                      |     
|===============================================================|     
     
Zip created at usbd_hid.zip     
+ nrfutil -v -v -v -v dfu usb-serial -pkg usbd_hid.zip -p /dev/cu.usbmodem14101 -b 115200     
2022-07-06 23:30:04,616 Using board at serial port: /dev/cu.usbmodem14101     
2022-07-06 23:30:04,618 Sending Application image.     
2022-07-06 23:30:38,027 Serial: Set Packet Receipt Notification 0     
2022-07-06 23:30:38,027 SLIP: --> [2, 0, 0]     
2022-07-06 23:30:39,028 SLIP: --> [7]     
Traceback (most recent call last):     
  File "/usr/local/bin/nrfutil", line 8, in <module>     
    sys.exit(cli())     
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1128, in __call__     
    return self.main(*args, **kwargs)     
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1053, in main     
    rv = self.invoke(ctx)     
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1659, in invoke     
    return _process_result(sub_ctx.command.invoke(sub_ctx))     
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1659, in invoke     
    return _process_result(sub_ctx.command.invoke(sub_ctx))     
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1395, in invokehid.z
    return ctx.invoke(self.callback, **ctx.params)     
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 754, in invoke     
    return __callback(*args, **kwargs)     
  File "/usr/local/lib/python3.9/site-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.9/site-packages/nordicsemi/__main__.py", line 980, in do_serial     
    dfu.dfu_send_images()     
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu.py", line 127, in dfu_send_images     
    self._dfu_send_image(self.manifest.application)     
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu.py", line 88, in _dfu_send_image     
    self.dfu_transport.open()     
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 217, in open     
    self.__get_mtu()     
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 366, in __get_mtu     
    self.mtu = struct.unpack('<H', bytearray(response))[0]     
TypeError: cannot convert 'NoneType' object to bytearray

Note that the delay between the output of Line 21 and the output of Line 22 is over 30 seconds long. I thought it was just going to crash as usual. But you can see that we are getting a few slip messages to appear before the crash.

For a weird sanity check, I called the nrfutil dfu command with serial instead of usb-serial, hoping that things might magically work out. As expected, it still didnt work. Just sharing the output in case there is anything valuable there:

+ nrfutil pkg generate --hw-version 52 --sd-req 0xCA --application-version 1 --application ../nrf-sdk/examples/peripheral/usbd_hid_generic/pca10056/blank/armgcc/_build/nrf52840_xxaa.hex usbd_hid.zip                    
                                                                                                                                                                                                                          
|===============================================================|                                                                                                                                                         
|##      ##    ###    ########  ##    ## #### ##    ##  ######  |                                                                                                                                                         
|##  ##  ##   ## ##   ##     ## ###   ##  ##  ###   ## ##    ## |                                                                                                                                                         
|##  ##  ##  ##   ##  ##     ## ####  ##  ##  ####  ## ##       |                                                                                                                                                         
|##  ##  ## ##     ## ########  ## ## ##  ##  ## ## ## ##   ####|                                                                                                                                                         
|##  ##  ## ######### ##   ##   ##  ####  ##  ##  #### ##    ## |                                                                                                                                                         
|##  ##  ## ##     ## ##    ##  ##   ###  ##  ##   ### ##    ## |                                                                                                                                                         
| ###  ###  ##     ## ##     ## ##    ## #### ##    ##  ######  |                                                                                                                                                         
|===============================================================|                                                                                                                                                         
|You are not providing a signature key, which means the DFU     |                                                                                                                                                         
|files will not be signed, and are vulnerable to tampering.     |                                                                                                                                                         
|This is only compatible with a signature-less bootloader and is|                                                                                                                                                         
|not suitable for production environments.                      |                                                                                                                                                         
|===============================================================|

Zip created at usbd_hid.zip
+ nrfutil -v -v -v -v dfu serial -pkg usbd_hid.zip -p /dev/cu.usbmodem14101 -b 115200
2022-07-06 23:36:00,307 Using board at serial port: /dev/cu.usbmodem14101
2022-07-06 23:36:00,309 Sending Application image.
2022-07-06 23:36:33,753 SLIP: --> [9, 1]
2022-07-06 23:36:34,758 Serial: No ping response
2022-07-06 23:36:34,758 SLIP: --> [9, 2]
2022-07-06 23:36:35,761 Serial: No ping response
2022-07-06 23:36:35,761 SLIP: --> [9, 3]
2022-07-06 23:36:36,766 Serial: No ping response
2022-07-06 23:36:36,766 SLIP: --> [9, 4]
2022-07-06 23:36:37,771 Serial: No ping response
2022-07-06 23:36:37,771 SLIP: --> [9, 5]
2022-07-06 23:36:38,776 Serial: No ping response
2022-07-06 23:36:38,776 SLIP: --> [9, 6]
2022-07-06 23:36:39,776 Serial: No ping response
2022-07-06 23:36:39,776 SLIP: --> [9, 7]
2022-07-06 23:36:40,782 Serial: No ping response
2022-07-06 23:36:40,782 SLIP: --> [9, 8]
2022-07-06 23:36:41,786 Serial: No ping response
2022-07-06 23:36:41,786 SLIP: --> [9, 9]
2022-07-06 23:36:42,788 Serial: No ping response
2022-07-06 23:36:42,788 SLIP: --> [9, 10]
2022-07-06 23:36:43,792 Serial: No ping response
2022-07-06 23:36:43,792 SLIP: --> [9, 11]
2022-07-06 23:36:44,795 Serial: No ping response
2022-07-06 23:36:44,796 SLIP: --> [9, 12]
2022-07-06 23:36:45,799 Serial: No ping response
2022-07-06 23:36:45,799 SLIP: --> [9, 13]
2022-07-06 23:36:46,801 Serial: No ping response
2022-07-06 23:36:46,801 SLIP: --> [9, 14]
2022-07-06 23:36:47,805 Serial: No ping response
2022-07-06 23:36:47,805 SLIP: --> [9, 15]
2022-07-06 23:36:48,811 Serial: No ping response
2022-07-06 23:36:48,811 SLIP: --> [9, 16]
2022-07-06 23:36:49,815 Serial: No ping response
2022-07-06 23:36:49,815 SLIP: --> [9, 17]
2022-07-06 23:36:50,819 Serial: No ping response
2022-07-06 23:36:50,819 SLIP: --> [9, 18]
2022-07-06 23:36:51,823 Serial: No ping response
2022-07-06 23:36:51,824 SLIP: --> [9, 19]
2022-07-06 23:36:52,828 Serial: No ping response
2022-07-06 23:36:52,829 SLIP: --> [9, 20]
2022-07-06 23:36:53,831 Serial: No ping response
2022-07-06 23:36:53,831 SLIP: --> [9, 21]
2022-07-06 23:36:54,836 Serial: No ping response
2022-07-06 23:36:54,836 SLIP: --> [9, 22]
2022-07-06 23:36:55,839 Serial: No ping response
2022-07-06 23:36:55,839 SLIP: --> [9, 23]
2022-07-06 23:36:56,844 Serial: No ping response
2022-07-06 23:36:56,844 SLIP: --> [9, 24]
2022-07-06 23:36:57,848 Serial: No ping response
2022-07-06 23:36:57,848 SLIP: --> [9, 25]
2022-07-06 23:36:58,851 Serial: No ping response
2022-07-06 23:36:58,851 SLIP: --> [9, 26]
2022-07-06 23:36:59,854 Serial: No ping response
2022-07-06 23:36:59,854 SLIP: --> [9, 27]
2022-07-06 23:37:00,855 Serial: No ping response
2022-07-06 23:37:00,855 SLIP: --> [9, 28]
2022-07-06 23:37:01,856 Serial: No ping response
2022-07-06 23:37:01,856 SLIP: --> [9, 29]
2022-07-06 23:37:02,857 Serial: No ping response
2022-07-06 23:37:02,858 SLIP: --> [9, 30]
2022-07-06 23:37:03,858 Serial: No ping response
Traceback (most recent call last):
  File "/usr/local/bin/nrfutil", line 8, in <module>
    sys.exit(cli())
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1128, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1053, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1659, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1659, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 1395, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.9/site-packages/click/core.py", line 754, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/__main__.py", line 1063, in serial
    do_serial(package, port, connect_delay, flow_control, packet_receipt_notification, baud_rate, serial_number, True,
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/__main__.py", line 980, in do_serial
    dfu.dfu_send_images()
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu.py", line 127, in dfu_send_images
    self._dfu_send_image(self.manifest.application)
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu.py", line 88, in _dfu_send_image
    self.dfu_transport.open()
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 214, in open
    raise NordicSemiException("No ping response after opening COM port")
pc_ble_driver_py.exceptions.NordicSemiException: No ping response after opening COM port

There are maybe 2 or 3 posts in Google that are showing up with this same error message with nRF52840 nrfutil dfu attempts...but none of them really have a solution. Someone mentioned disabling the MSD, but this XIAO module doesnt appear as a flash storage icon when plugged in, so I dont think that is relevant. Im not sure how to proceed further...do those slip messages mean anything to you?

[cor10]

UPDATE:

I realize that I have downloaded the standard nrfutil tool, not the adafruit-nrfutil tool. So I uninstalled the former and installed the latter, and also tweaked a couple of the inputs, and was able to get these new, more informative error messages:

+ adafruit-nrfutil dfu serial -pkg usbd_hid.zip -p /dev/cu.usbmodem14101 -b 115200
Upgrading target on /dev/cu.usbmodem14101 with DFU package /Users/cortensinger/Augmental/dfu-dev/usbd_hid.zip. Flow control is disabled, Dual bank, Touch disabled
Timed out waiting for acknowledgement from device.

Failed to upgrade target. Error is: No data received on serial port. Not able to proceed.
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/__main__.py", line 296, in serial
    dfu.dfu_send_images()
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu.py", line 235, in dfu_send_images
    self._dfu_send_image(HexType.APPLICATION, self.manifest.application)
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu.py", line 199, in _dfu_send_image
    self.dfu_transport.send_start_dfu(program_mode, softdevice_size, bootloader_size,
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 179, in send_start_dfu
    self.send_packet(packet)
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 243, in send_packet
    ack = self.get_ack_nr()
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 282, in get_ack_nr
    raise NordicSemiException("No data received on serial port. Not able to proceed.")
nordicsemi.exceptions.NordicSemiException: No data received on serial port. Not able to proceed.

Possible causes:
- Selected Bootloader version does not match the one on Bluefruit device.
    Please upgrade the Bootloader or select correct version in Tools->Bootloader.
- Baud rate must be 115200, Flow control must be off.
- Target is not in DFU mode. Ground DFU pin and RESET and release both to enter DFU mode.

+ adafruit-nrfutil dfu serial -pkg usbd_hid.zip -p /dev/cu.usbmodem14101 -b 115200
Upgrading target on /dev/cu.usbmodem14101 with DFU package /Users/cortensinger/Augmental/dfu-dev/usbd_hid.zip. Flow control is disabled, Dual bank, Touch disabled

Failed to upgrade target. Error is: read failed: [Errno 6] Device not configured
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/serial/serialposix.py", line 575, in read
    buf = os.read(self.fd, size - len(read))
OSError: [Errno 6] Device not configured

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/__main__.py", line 296, in serial
    dfu.dfu_send_images()
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu.py", line 235, in dfu_send_images
    self._dfu_send_image(HexType.APPLICATION, self.manifest.application)
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu.py", line 206, in _dfu_send_image
    self.dfu_transport.send_firmware(firmware)
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 213, in send_firmware
    self.send_packet(pkt)
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 243, in send_packet
    ack = self.get_ack_nr()
  File "/usr/local/lib/python3.9/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 264, in get_ack_nr
    temp = [x for x in self.serial_port.read(6)]
  File "/usr/local/lib/python3.9/site-packages/serial/serialposix.py", line 581, in read
    raise SerialException('read failed: {}'.format(e))
serial.serialutil.SerialException: read failed: [Errno 6] Device not configured

Possible causes:
- Selected Bootloader version does not match the one on Bluefruit device.
    Please upgrade the Bootloader or select correct version in Tools->Bootloader.
- Baud rate must be 115200, Flow control must be off.
- Target is not in DFU mode. Ground DFU pin and RESET and release both to enter DFU mode.

Out of the listed possible causes, it appears that we can rule out bullet point 2 as we are setting the baud rate specifically, and we see in the output that Flow Control is disabled. So it could be the bootloader issue....or possibly the DFU state, since I have not done anything to step it into DFU state so far. However, I have had difficulty finding out how to manually place the device into DFU mode....its unclear as to what the DFU pin is. I grounded the RST pin, and that is actually what got the second of the 2 error messages I just shared to display.

Also, I realized that this XIAO module does appear as a flash storage icon when plugged in, which means I could possibly try the previous solution I came across which involved disabling the MSD. Is there a known way to disable this aside from JLINK (which is what is recommended in the docs)? Because if I hook up the JLINK connections, I may as well just program the device that way...

[Vidar Berg]

Hello,

I was not able to find any documentation that confirmed what bootloader this module shipped with either, but the fact that it enumerates as a mass storage device indicates that it is not executing our bootloader, at least . Maybe it supports drag&drop programming instead?

Another alternative to DFU over USB is to use one of the Debug outputs from your nRF52840DK to program the module. Just remember that the module must have the same VDD voltage as the DK because the OB Jlink doesn't have a built-in level shifter like you will find in a standalone J-link programmer.

[mytzyiay]

cor10 said:

So it could be the bootloader issue....or possibly the DFU state, since I have not done anything to step it into DFU state so far.

Yeah, I would wonder whether the bootloader is running, or if it has transferred control to an app that enables the USB CDC ACM functionality but doesn't accept the SLIP command format.  That would explain why you're able to open the USB serial device, but the board isn't responding to commands.

The Xiao BLE docs say:

On my nRF52840 Dongles, I also have to hit the reset button (just once) to get it back to the Open Bootloader so I can upload new code via nrfutil.

cor10 said:

I grounded the RST pin, and that is actually what got the second of the 2 error messages I just shared to display.

I would guess that if you asserted RST and never released it, you won't even see the /dev/cu.* device node anymore because the USB interface on the nRF52840 chip is inactive.

[cor10]

Vidar Berg said:

the fact that it enumerates as a mass storage device indicates that it is not executing our bootloader, at least .

Why is this the case? For example, when I plug in the nRF52840 DK, it also appears as a flash storage icon. So why does this fact help us distinguish that it is not a Nordic bootloader?

Vidar Berg said:

Maybe it supports drag&drop programming instead?

I can try. In this case, would I just be simply Drag/Dropping the compiled .HEX file for my application, or would I Drag/Drop the newly created .ZIP package from the attempts with nrfutil dfu?

mytzyiay said:

I would guess that if you asserted RST and never released it, you won't even see the /dev/cu.* device

I would agree. To be clear, I only temporarily grounded the RST pin with a jumper cable (unsoldered) - I didnt leave it grounded. I would have liked to simultaneously ground the "DFU pin" temporarily as well, given that is what the error message suggests. But I dont know what the "DFU pin" is, so I just tried it with only the RST pin. The temporary grounding is what seems to have stepped the XIAO module into a different mode, which is what produced the second of the two error messages that I shared from the adafruit-nrfutil output. For now, I can keep trying to play with the Reset Button, and see if that can get anywhere.

Otherwise, it is looking more and more likely that I will just solder up some connections to the SWD pads on the module and program it using a JLINK like I have done with other boards. Using the Debug Outputs from the nRF52840 DK seems more difficult than this JLINK/SWD option...I just feel like I am very close to getting it to work with the USB....

[mytzyiay]

cor10 said:

To be clear, I only temporarily grounded the RST pin with a jumper cable (unsoldered) - I didnt leave it grounded.

If the device node is still present, and you're getting "Device not configured" (ENXIO) when you try to talk to it, that suggests to me that you might have successfully activated the bootloader but your host isn't able to talk to it due to USB interop bugs.  e.g. maybe the bootloader has a different version of the USB stack from the main app

If you have a Linux box or Raspberry Pi lying around, maybe try flashing with one of those?

cor10 said:

Otherwise, it is looking more and more likely that I will just solder up some connections to the SWD pads on the module and program it using a JLINK like I have done with other boards.

IMO the support for these USB bootloaders is pretty half-baked, even on the official Nordic dongles.  I wonder if they'd accept a pull request to clean it up.

[cor10]

Hello mytzyiay and Vidar Berg,

I am having trouble replying to the most recent comment left by Mytzjay, but I was able to learn a bit more about the device. I found some information on board my XIAO module that mentions the bootloader, as well as some other high level details. Take a look:

UF2 Bootloader 0.6.2-12-g459adc9-dirty lib/nrfx (v2.0.0) lib/tinyusb (0.10.1-293-gaf8e5a90) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)
Model: Seeed XIAO nRF52840
Board-ID: Seeed_XIAO_nRF52840_Sense
Date: Nov 30 2021
SoftDevice: S140 7.3.0

Right off the bat, I notice that my SoftDevice s140 is version 7.0.1, while this XIAO module has s140 version 7.0.3. Could this difference in version be causing these issues?

Aside from that, I am not entirely sure how to make sense of the bootloader information. Do these bootloader details give us a better understanding of what is going on? Any help is greatly appreciated.

EDIT: I connected a JLINK to the XIAO module by soldering wires to the SWDIO, SWDCLK, RST, GND and 3.3V pins. This method is working for me and I am getting all of my code onto the device as expected. Thank you for working with me to try and help debug using the USB as a means of DFU. If this bootloader information that I shared sheds light on my previous failures, I would still love to learn what is going on...plus I have to program a handful of these boards and it would be easier over USB, though not needed.

[Vidar Berg]

Hello,

I'm glad to hear that you were able to program the module through the debug interface.

cor10 said:

Why is this the case? For example, when I plug in the nRF52840 DK, it also appears as a flash storage icon. So why does this fact help us distinguish that it is not a Nordic bootloader?

The main USB on the DK is connected to the standalone J-link interface chip and not to the nRF52840's USB (the nRF usb is the one on the side). The J-link will enumerate as a composite device with 1-2 VCOM ports and a mass storage device.

cor10 said:

I am having trouble replying to the most recent comment left by Mytzjay, but I was able to learn a bit more about the device. I found some information on board my XIAO module that mentions the bootloader, as well as some other high level details. Take a look:

UF2 is a different bootloader which you can read more about here: https://learn.adafruit.com/adafruit-feather-m0-express-designed-for-circuit-python-circuitpython/uf2-bootloader-details

[ufocia]

It looks like I hosed the softdevice on my XIAO using one/some of the NRF5 SDK examples. The UF2 mass storage bootloader interface takes the executables, but they simply don't work.(It could be that I zapped the bootloader in the process as well). Any ideas how to use the UF2 bootloader to replace the softdevice and/or the UF2 bootloader itself. I'd like to avoid messing with j-link for the moment.