Can the standard bootloader in the nrf52840 dongle be used with the DFU Trigger library for USB firmware updates (nrfutil)?

I have the DFU Trigger code added to my application, and am using nrfutil to upload the package over USB.  If I press the reset/DFU button on the dongle the process works fine.  If I try to use the DFU Trigger, I get the following error:

2022-10-01 22:04:29,304 Serial: Device is either not in bootloader mode, or using an unsupported bootloader.
2022-10-01 22:04:29,321 Serial: Set Packet Receipt Notification 0
Traceback (most recent call last):
File "/usr/local/bin/nrfutil", line 8, in <module>
sys.exit(cli())
File "/usr/lib/python3/dist-packages/click/core.py", line 829, in __call__
return self.main(*args, **kwargs)
File "/usr/lib/python3/dist-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
File "/usr/lib/python3/dist-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/lib/python3/dist-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/lib/python3/dist-packages/click/core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python3/dist-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.9/dist-packages/nordicsemi/__main__.py", line 1032, 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/dist-packages/nordicsemi/__main__.py", line 990, in do_serial
dfu.dfu_send_images()
File "/usr/local/lib/python3.9/dist-packages/nordicsemi/dfu/dfu.py", line 127, in dfu_send_images
self._dfu_send_image(self.manifest.application)
File "/usr/local/lib/python3.9/dist-packages/nordicsemi/dfu/dfu.py", line 88, in _dfu_send_image
self.dfu_transport.open()
File "/usr/local/lib/python3.9/dist-packages/nordicsemi/dfu/dfu_transport_serial.py", line 217, in open
self.__get_mtu()
File "/usr/local/lib/python3.9/dist-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

I am using USB CDC for data transfer, but I do have the COMM and DATA interfaces have been set to 1 & 2.

Is the standard bootloader (the one that comes with the dongle) compatible with the DFU Trigger?  Or do I need to add a secure or open bootloader.

If I need to replace the bootloader, do I need a settings.hes, or just merge the newly built bootloader with the softdevice (s140)?

Thanks,

--jeff

Parents
  • We're using nRF5_SDK_15.3.0_59ac345, which should coincide with the manufacture date of the dongles I'm testing, if that matters.  Since we're close to putting hundreds of these into a large warehouse, it would be great to be able to remotely fix any issues, but because we're close to deploying, I was hoping to avoid changing the SDK version.

    It looks like the issue is a missing MTU value, which I would think would not be a factor in the USB transport (MTU is usually associated with BLE).

    Thanks,

    --jeff

  • Hi Jeff

    Do you know which LF clock source you are using, as set through the LFCLKSRC register?

    We have seen similar issues earlier, where the choice of LF clock configuration before activating the bootloader could cause issues for the bootloader. 

    Also, are you using the watchdog in your application?

    Best regards
    Torbjørn

  • I'm using the default selection of the LF CLK that was set by the example I built the project from:

    //  NRFX_CLOCK_CONFIG_LF_SRC  - LF Clock Source
     
    // <0=> RC 
    // <1=> XTAL 
    // <2=> Synth 
    // <131073=> External Low Swing 
    // <196609=> External Full Swing 
    
    #ifndef NRFX_CLOCK_CONFIG_LF_SRC
    #define NRFX_CLOCK_CONFIG_LF_SRC 1
    #endif
    
Reply Children
  • Hi Jeff

    Can you confirm that you are using the standard nRF52840 dongle, or have you made your own PCB?

    All the DFU trigger code is toggle the GPIO connected to the reset pin, which will cause the toggle to reset and start in bootloader mode. Would you be able to put a scope on the reset pin and see if it is actually toggled when you try to activate the DFU trigger library?

    Best regards
    Torbjørn

  • As the title of my query shows, the problem is being exhibited by a stock nrf52840 dongle.  It is not an issue with an individual unit, as I've tried it on several.  Unfortunately, our company doesn't have the resources to debug your hardware, in order to find the cause of a software issue.

    Debugging the dongle unit over USB, while using USB to perform a function such as the DFU Trigger is close to, if not impossible.  I've seen conflicting reports about whether debugging on the dongle over USB is possible at all.

    Finding the right combination of sdk_config.h settings to implement the DFU Trigger took days, until I found an obscure blog post that mentioned the re-assignment of the USB interface values.

    I've not found a complete example of the DFU Trigger using the USB interface.  The BLE OTA seems to have much more interest, although in our case it doesn't make sense.  Our dongles are used in the central role, not peripheral, so building a GATT/GAP service into the firmware just to switch to DFU mode is not practical.

    Thanks,

    --jeff

  • Hi Jeff

    jkase said:
    Unfortunately, our company doesn't have the resources to debug your hardware, in order to find the cause of a software issue.

    If are running your own software you might have to debug the hardware at some point ;)

    But in this case it should be enough to look for a reset of the USB dongle. When you press the button to engage the bootloader I assume you see the USB CDC comport disappear?

    Is the same happening when you activate the DFU trigger library?

    jkase said:
    Debugging the dongle unit over USB, while using USB to perform a function such as the DFU Trigger is close to, if not impossible.  I've seen conflicting reports about whether debugging on the dongle over USB is possible at all.

    In this case I would recommend soldering the P1 connector on the back of the dongle, allowing you to connect an external debugger to the dongle directly. 

    Alternatively you can use a nRF52840DK to develop your dongle application, since it has a built in debugger, and then deploy on the dongle later on when the development is complete. 

    jkase said:
    Our dongles are used in the central role, not peripheral, so building a GATT/GAP service into the firmware just to switch to DFU mode is not practical.

    Are you using standard BLE services, or are you doing something proprietary?

    If you are doing something proprietary you could always implement your own proprietary characteristic to start DFU that you store in the server on the peripheral side. 

    Then you don't need to go to the trouble of setting up a GATT server on the central side also. 

    Best regards
    Torbjørn

Related