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?

[Einar Thorsrud]

Hi,

I don't have an explanation at this point, but it seems strange. Serial DFU can use retransmission on the application layer, so it could be that there is a log of data corruption, making it take a long time. it seems like a long shot, though.

Some questions:

• When you test with a logic analyzer, how does is the activity on the UART lines? Is there no activity for all those idle seconds in the initial phase?
• Have you tested simple UART communication (not DFU)?
  • Could there be some issue with the UART lines causing unstable communication?
  • Can you make sure to request the HF clock so that we know that the issue is not caused by an inaccurate clock in the nRF (the high-frequency RC oscillator has a too high tolerance for UART, so it could cause communication problems if you are unlucky).

[DBT]

There is no UART activity during the first 35 seconds.

The Application is basically the serial example in the Mesh SDK, so after the app is loaded I communicate with the app using interactive_pyaci.py and that works fine.   

Looking at the UART signals with a scope, they look fine.

And once the DFU download starts it works fine (except for the timeouts)

I'm guessing that the nrfutil is looking at some kind of port status but times out after 30 seconds.  The nRF52840-Preview-DK board provides that status but the FTDI USB-to-UART adapter cable I'm using doesn't.  This is just a suspicion but it seems to agree with the symptoms.