DFU via nrfutil is taking longer to start on our custom board than it does on the nRF52840-Preview-DK board

[DBT]

I tried out DFU functionality initially using nRF52840-PreviewDK and UART transport

When downloading an app via DFU, It takes about 6 seconds from the time I start nrfutil until the progress bar shows.

Now I've ported DFU code over to our custom board and it takes about 35 seconds from the time I start nrfutil until the progress bar shows.

Why is it taking so much longer to start on our custom board?

To be clear, the DFU download works on our board and I can confirm that the app is running after DFU download.

I just don't understand why nrfutil is taking longer to start.  I confirmed with a scope that nrfutil doesn't start sending data over the UART until after about 35 seconds, and our custom board responds to the initial message within about 50 microseconds, so it's not like nrfutil is pinging our board and its taking our board longer to start responding.  It seems like its something happening in nrfutil rather than in the bootloader on our board.

Our board does not use flow control, so I use the "-fc 0" command line option: nrfutil dfu serial -pkg app_dfu_package.zip -p COM13 -b 115200 -fc 0

The nRF52840-PreviewDK board apparently does use flow control, but I tried using "-fc 0" when downloading to the nRF52840-PreviewDK board and it didn't appear to affect the start time.

Do you have any insights on this issue?

[DBT]

The above screenshot is while using the FTDI USB-to-UART cable.  For comparison, this is the screenshot when using the nRF52840-Preview-DK "as-is".  It has 4 seconds of start up delay instead of 34 seconds.  It looks like a 30-second timeout is happening when the USB-to-UART cable is used.

[DBT]

Another clue:  If I add "-t 15" to the command line, the startup delay is reduced by 15 seconds.

The response to "nrfutil dfu serial --help" is:

Usage: nrfutil dfu serial [OPTIONS]

Perform a Device Firmware Update on a device with a bootloader that
supports UART serial DFU.

Options:
-pkg, --package FILE Filename of the DFU package. [required]
-p, --port TEXT Serial port address to which the device is
connected. (e.g. COM1 in windows systems,
/dev/ttyACM0 in linux/mac)
-cd, --connect-delay INTEGER Delay in seconds before each connection to
the target device during DFU. Default is 3.
-fc, --flow-control BOOLEAN To enable flow control set this flag to 1
-prn, --packet-receipt-notification INTEGER
Set the packet receipt notification value
-b, --baud-rate INTEGER Set the baud rate
-snr, --serial-number TEXT Serial number of the device. Ignored if
--port is set.
-t, --timeout INTEGER Set the timeout in seconds for board to
respond (default: 30 seconds)
--help Show this message and exit.

The 30-second timeout that is occurring must be this board response timeout.

So why is a board response timeout happening at the beginning only when using an external cable (or an interface without flow control) 

[Einar Thorsrud]

Hi,

I have looked into this and discussed it with one of the developers, but we are not sure why this happens. I will make an internal bug report so that we will investigate further, but for now, I recommend you just a short timeout as a workaround.

[DBT]

I have adjusted NRF_BL_DFU_CONTINUATION_TIMEOUT_MS as a workaround.

I guess I could have also used the “-t” command line argument on nrfutil as a workaround.

Please let me know once the long-term fix is in place.

[mmbedded]

I think it is related to this issue: https://github.com/NordicSemiconductor/pc-nrfutil/issues/228

I workaround it by modifying dfu_transport_serial.py script - In open method under DfuTransportSerial class, I put call self.__ensure_bootloader() under statement 'if not self.do_ping' (Recompile it after)
In my opinion this should be called in usb-serial mode, not in regular serial mode