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

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

mmbedded — Wed, 08 Jan 2020 18:53:00 GMT

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

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

DBT — Mon, 12 Aug 2019 12:44:54 GMT

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.

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

Einar Thorsrud — Mon, 12 Aug 2019 11:23:52 GMT

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.

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

DBT — Fri, 09 Aug 2019 13:58:59 GMT

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)

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

DBT — Fri, 09 Aug 2019 13:03:16 GMT

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.

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

DBT — Fri, 09 Aug 2019 12:55:58 GMT

The problem is that it takes about 35 seconds to START after you issue the command, not how long it takes to finish after it starts.

I changed the command prompt in my batch file to show the time when the command is issued

So the nrfutil command is sent at 8:50:49 and the first message from nrfutil is at 8:51:23 (34 seconds later)

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

Einar Thorsrud — Fri, 09 Aug 2019 06:57:36 GMT

Hi,

That was the log I was thinking about. Looking at the timestamps it doe snot look like this took more than a few seconds. Do you have a similar log output from when you see the problem?

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

DBT — Thu, 08 Aug 2019 13:50:28 GMT

This is what comes up in the terminal window:

C:\nordic\nRF5_SDK_15.3.0_59ac345\nRF5SDK153059ac345\nRF5_SDK_15.3.0_59ac345\examples\ble_peripheral\ble_app_blinky\pca10056\s140\ses\Output\Release\Exe>nrfutil dfu serial -pkg ble_blinky_app_dfu_package.zip -p COM13 -b 115200 -fc 0
2019-08-08 09:47:14,815 Serial: Set Packet Receipt Notification 0
2019-08-08 09:47:14,848 Serial: Selecting Object: type:1
2019-08-08 09:47:14,864 Serial: Object selected: max_size:512 offset:0 crc:0
2019-08-08 09:47:14,880 Serial: Streaming Data: len:141 offset:0 crc:0x00000000
2019-08-08 09:47:15,072 Serial: Selecting Object: type:2
2019-08-08 09:47:15,088 Serial: Object selected: max_size:4096 offset:0 crc:0
2019-08-08 09:47:15,198 Serial: Streaming Data: len:4096 offset:0 crc:0x00000000
[######------------------------------] 18% 00:02:312019-08-08 09:47:15,694 Serial: Streaming Data: len:4096 offset:4096 crc:0xA0E6B9DD
[#############-----------------------] 36% 00:01:572019-08-08 09:47:16,190 Serial: Streaming Data: len:4096 offset:8192 crc:0xC10085B8
[###################-----------------] 54% 00:01:232019-08-08 09:47:16,686 Serial: Streaming Data: len:4096 offset:12288 crc:0x64C25F08
[##########################----------] 73% 00:00:312019-08-08 09:47:17,181 Serial: Streaming Data: len:4096 offset:16384 crc:0xCB18C2BA
[################################----] 91% 00:00:092019-08-08 09:47:17,665 Serial: Streaming Data: len:1884 offset:20480 crc:0x3F1CF308
[####################################] 100%
Device programmed.

That's more detail than normally shows during the DFU process.

Is that what you wanted or is there a log file somewhere you're looking for?

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

Einar Thorsrud — Thu, 08 Aug 2019 13:38:57 GMT

Hi,

The path was based on a few assumptions. It would be there if you are using nrfutil on a windows PC, and have Pything installed in C:\Python27 and installed nrfutil using pip. You will not find the dfu_transport_serial.py file if you are using a nrfutil that has been packaged as a .exe file.

Can you try to install the latest nrfutil via pip? Please note that nrfutil requires python 2 (not 3). When you have python 2 installed you can call "pip2 install nrfutil" to install it. Then you will get the newest nrfutil (5.2.0) as a python script and it will automatically be in your path. Now you can do the change I suggested (adjust for any difference in where Python is in your system), and you will get a lot of logs during the DFU process.

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

DBT — Thu, 08 Aug 2019 13:28:30 GMT

I have windows, but C:\Python27\Lib\site-packages\nordicsemi\dfu\dfu_transport_serial.py doesn't exist on my PC.

dfu_transport_serial.py isn't anywhere on my PC.

C:\Python27\Lib\site-packages does not have a nordicsemi subdirectory.

Do I need to install something?

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

Einar Thorsrud — Thu, 08 Aug 2019 12:11:42 GMT

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.

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

DBT — Wed, 07 Aug 2019 17:24:15 GMT

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.

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)
Connect powered USB cable to J3 (marked nRF USB on the silkscreen)
Press and hold button 4 while toggling SW8 (marked Power on the silkscreen) from off to on. (to put it in DFU mode)
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.

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

DBT — Tue, 06 Aug 2019 12:59:49 GMT

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.

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

Einar Thorsrud — Tue, 06 Aug 2019 12:04:56 GMT

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

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

DBT — Mon, 05 Aug 2019 20:04:37 GMT

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