DFU don't start with nrfutil dfu ble

[Yosi.stx]

Hi, 

I face a problem when trying to perform a DFU firmware update via command line using nrfutil dfu ble. 

I'm using windows 10 and nrfutil.exe version 3.5.0

nrfutil dfu ble -ic NRF52 -pkg app_dfu_package.zip -p COM7 -n "DfuBoot_2018_07_18"
  [------------------------------------]    0%
Traceback (most recent call last):
  File "nordicsemi\__main__.py", line 983, in <module>
  File "site-packages\click\core.py", line 722, in __call__
  File "site-packages\click\core.py", line 697, in main
  File "site-packages\click\core.py", line 1066, in invoke
  File "site-packages\click\core.py", line 1066, in invoke
  File "site-packages\click\core.py", line 895, in invoke
  File "site-packages\click\core.py", line 535, in invoke
  File "nordicsemi\__main__.py", line 834, in ble
  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_ble.py", line 450, in open
  File "nordicsemi\dfu\dfu_transport_ble.py", line 106, in open
  File "site-packages\pc_ble_driver_py\ble_driver.py", line 126, in wrapper
pc_ble_driver_py.exceptions.NordicSemiException: Failed to open. Error code: 13
Failed to execute script __main__

I am using for the PCA10040 EVB as connectivity device

The SoftDevice is: s132_nrf52_5.0.0_softdevice.hex

The SDK is: nRF5_SDK_14.2.0_17b948a

The comport is COM7, since this is the com that I see when using the "nRF Connect" PC application and also with the Device manager.

     

I am sure that I have the connectivity firmware on the connectivity device, since when I try it with option -f it give a feedback: "Board already flashed with connectivity firmware."

When I am using the  "nRF Connect" PC application, the secure DFU process is working, but I want to use the command line DFU since I have the nrfutil python source code and in this way I may try to change some timeouts for our development process.

Thanks,

Yosi.

[Yosi.stx]

The target device is "our" board (not PCA10040) compiled with our Public key while the ZIP package is appropriate one created with the correct private key. I am sure about it since the whole DFU process is working perfectly fine when I am using exactly the same combination of HW, FW and ZIP package but running the DFU from the nrf Connect application.

I can't use the sample from the SDK since our board has different pin layout from the PCA10040.

I put Device Monitor Studio on the UART communication between the PC and the connectivity device, and got this info, maybe it can help if an expert will look on it?

[Yosi.stx]

I even tried to change to connectivity FW to:

connectivity_1.0.1_115k2_with_s132_3.0.hex

according to this recommendation: here

It also did not help, I still get the following feedback:

C:\Python27\Lib\site-packages\nordicsemi>__main__.py dfu ble -ic NRF52 -p COM7 -n "DfuBoot_2018_08_16" -pkg app_128FF.zip -f
Board already flashed with connectivity firmware.
  [------------------------------------]    0%
Traceback (most recent call last):
  File "C:\Python27\Lib\site-packages\nordicsemi\__main__.py", line 987, in <module>
    cli()
  File "C:\Python27\lib\site-packages\click\core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "C:\Python27\lib\site-packages\click\core.py", line 697, in main
    rv = self.invoke(ctx)
  File "C:\Python27\lib\site-packages\click\core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "C:\Python27\lib\site-packages\click\core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "C:\Python27\lib\site-packages\click\core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "C:\Python27\lib\site-packages\click\core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "C:\Python27\Lib\site-packages\nordicsemi\__main__.py", line 838, in ble
    dfu.dfu_send_images()
  File "C:\Python27\lib\site-packages\nordicsemi\dfu\dfu.py", line 129, in dfu_send_images
    self._dfu_send_image(self.manifest.application)
  File "C:\Python27\lib\site-packages\nordicsemi\dfu\dfu.py", line 90, in _dfu_send_image
    self.dfu_transport.open()
  File "C:\Python27\lib\site-packages\nordicsemi\dfu\dfu_transport_ble.py", line 450, in open
    self.dfu_adapter.open()
  File "C:\Python27\lib\site-packages\nordicsemi\dfu\dfu_transport_ble.py", line 106, in open
    self.adapter.driver.open()
  File "C:\Python27\lib\site-packages\wrapt\wrappers.py", line 562, in __call__
    args, kwargs)
  File "C:\Python27\lib\site-packages\pc_ble_driver_py\ble_driver.py", line 126, in wrapper
    raise NordicSemiException('Failed to {}. Error code: {}'.format(wrapped.__name__, err_code))
pc_ble_driver_py.exceptions.NordicSemiException: Failed to open. Error code: 13

needless to mention that I put the ZIP file "app_128FF.zip" in the location of 

C:\Python27\Lib\site-packages\nordicsemi

[Edvin]

Hello,

I see that you have tried many different solutions, from the list.

1: Are you sure you have added the nrfutil tool to your environment path on the computer?

2: You do have two devices, right? One for the connectivity board, and one for your target board (the DFU target)?

3: Is the connectivity board an nRF development kit, or is this also a custom board?

 

Regarding the different versions of the different tools. You can stick to the latest version of nrfutil, v 3.5.1 and Python 2.7.12 (which is what I use). I also tend to use "-f", since it ensures that the correct version of pc-ble-driver is flashed to the board (which depends on what version of nrfutil you use).

 

Best regards,

Edvin

[Yosi.stx]

Hello Edvin.

Thank you for the answer.

1) usually, for create zip packages, I worked with the nrfutil.exe that is in "c:\util\" folder which is on my PC environment path. And from there I began trying to do the DFU with nrfutil.

Only after I become desperate I started to use  __main__.py from:

"C:\Python27\Lib\site-packages\nordicsemi>" which obviously is not in the environment path. have to say that in both cases the result was: Error code: 13

2+3) the connectivity board:  PCA10040;  

target board: Our board (based on nRF52832), 

The combination of those boards can perform DFU when using the nrf Connect.

[Edvin]

Hello,

Do you use the debug bootloader projects? I don't see that it should cause any problems with opening the com-port, so it is a shot in the dark, but still worth a shot.

 

I have a  zip-folder which I used to test the nrfutil DFU operation once.

 

can you unzip it and test it? All you should have to do is to open flash_bootloader.bat in notepad, and change all the references to --snr 682654319 with --snr <SeggerID of your DFU chip>, and change COM20 with the corresponding COM port of your connectivity DK (Keep the brackets ").

Then you can just run the flash_bootloader.bat in CMD, and it should flash the bootloader, and do the DFU transfer using nrfutil.

DFU_test.zip

 

You probably need 2x DK to test this. If that doesn't work. What Segger JLink version do you have on your computer?

 

Best regards,

Edvin