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]

Update:  In addition, downloading a bootloader - app - softdevice combo doesn't work on our new board.

Based on my observation of LEDs during the process, I think 2 of the 3 entities are being downloaded, then there is a reboot but the bootloader times out before nrfutil attempts to download the third entity.

Here is what shows in my console at the end:

C:\umg\nordic\umg-dfu\Output\Release\Exe>C:\Users\TURNBODB\Downloads\Nordic\nrfutil dfu serial -pkg bl_sd_app_dfu_package.zip -p COM13 -b 115200 -fc 0
[###############################-----] 88% 00:00:08
Traceback (most recent call last):
File "nordicsemi\__main__.py", line 1464, in <module>
File "click\core.py", line 764, in __call__
File "click\core.py", line 717, in main
File "click\core.py", line 1137, in invoke
File "click\core.py", line 1137, in invoke
File "click\core.py", line 956, in invoke
File "click\core.py", line 555, in invoke
File "nordicsemi\__main__.py", line 1042, in serial
File "nordicsemi\__main__.py", line 956, in do_serial
File "nordicsemi\dfu\dfu.py", line 129, in dfu_send_images
File "nordicsemi\dfu\dfu.py", line 90, in _dfu_send_image
File "nordicsemi\dfu\dfu_transport_serial.py", line 214, in open
pc_ble_driver_py.exceptions.NordicSemiException: No ping response after opening COM port
[61948] Failed to execute script __main__

C:\umg\nordic\umg-dfu\Output\Release\Exe>pause
Press any key to continue . . .

[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.

[DBT]

I am able to reproduce this issue using a nRF52840-Preview-DK board where I use a separate USB-to-UART adapter/cable.  I tried both a cable from FTDI and a generic USB-to-UART adapter board that has a Silabs CP2102 chip on it.  Both worked to reproduce the 35-second startup delay, but the instructions below (specifically the wire colors) are for the FTDI cable.

1. I’m using FTDI cable TTL-2332RG-VIP-WE: https://www.ftdichip.com/Products/Cables/USBTTLSerial.htm
   1. Could also use TTL-232RG-VREG3V3-WE or TTL-232R-3V3 or TTL-232R-3V3-PCB or any USB-to-UART adapter that works at 3.3V on the UART side.
   2. Black wire = GND.  Connect to connector P1 pin 7 on the Preview-DK board
   3. Red wire = VDD.  Connect to connector P1 pin 1
   4. Orange wire = UART TX (transmit from PC to Nordic).  Connect to connector P6 pin 6 (marked P0.08 on the silkscreen)
   5. Yellow wire = UART RX (receive from Nordic to PC).  Connect to connector P6 pin 4 (marked P0.06 on the silkscreen)
2. Connect powered USB cable to J3 (marked nRF USB on the silkscreen)
3. Press and hold button 4 while toggling SW8 (marked Power on the silkscreen) from off to on. (to put it in DFU mode)
4. Use nrfutil to try to download an app (I used “nrfutil dfu serial -pkg ble_blinky_app_dfu_package_u.zip -p COM13 -b 115200 -fc 0” where COM13 corresponds to the FTDI cable)

This works to reproduce the 35-second startup delay.  The DFU download of the app works, but it takes about 35 seconds before any activity is seen on the UART lines.

This looks like an nrfutil issue.  It appears this happens whenever the UART connection has no flow control, even when the "-fc 0" option is used with nrfutil.

Please look into it and provide a solution ASAP.

[Einar Thorsrud]

Hi,

Unfortunately, I don't have a USB-serial converter at hand, so I have not been able to test today.

I am not sure you can conclude this is a nrfutil issue. Nrfutil is just a python script and is itself independent of the USB-serial bridge, though there could be some lower-level differences in the driver or similar.

It would be interesting to get some more information. Can you repeat the test with debug logging enabled in nrfutil? You can enable it by editing C:\Python27\Lib\site-packages\nordicsemi\dfu\dfu_transport_serial.py (assuming you use Windows), adding the following on line 63 (below the instantiation of the logger):

logger.setLevel(logging.DEBUG)

Please upload the log here.