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.

[Edvin]

Hello,

Are you sure that the COM port / the nRF is not used by another application? 

Try to power cycle the board before running the nrfutil command.

I just tested this, with the -f command:

nrfutil dfu ble -ic NRF52 -pkg application\app_dfu_package.zip -p COM20 -f -n "Nordic_Buttonless"

 

I have the following versions of Python and nrfutil:

>python --version
Python 2.7.12

>nrfutil version
nrfutil version 3.5.1

Can you try to update to nrfutil 3.5.1, and python 2.7.12, with the "-f" and try to close anything that may use the nRF connected to COM7.

 

Best regards,

Edvin

[Yosi.stx]

Hello,

I have tried a lot of things to make it work, yet with no success.

Regarding your suggestions:

1) The com port is not used by another application. 

2) I did power cycle of the board before running the nrfutil command.

3) My python is 2.7.12 and I have tried several versions of nrfutil (including 3.5.1) on two different PC's .

4) I did several tried with the "-f", always return with: "Board already flashed with connectivity firmware."

Other experiments I have tried:

5) Try with different evaluation boards with NRF51 and NRF52 as the connectivity board.

6) Changing to other version of the nrfutil (3.5.1; 3.4.0; 3.5.0)

7) Try with different PC with windows 7, with new installation of the "pip install nrfutil"

I searched google on: "nrfutil dfu ble error code 13"  and I have found that it is repeated issue for many other users, yet there was no good answer for this problem. 

Maybe it has to do with the fact that my target board is in DFU mode from the bootloader itself and not from "buttonless application"?

Could it be that there is an issue with the "pc_ble_driver_py" ?

Is there any importance to the order of the parameter given to "nrfutil dfu ble ..." command?

for example:

nrfutil dfu ble -ic NRF52 -n "DfuBoot_2018_08_16" -p COM45 -pkg Fake_app.zip
nrfutil dfu ble -ic NRF52 -p COM45 -pkg Fake_app.zip -n "DfuBoot_2018_08_16"

p.s. in the other PC the "Jlink CDC Uart port" was changed to COM45.

[retrostately]

It seems to me it has to be one of two things:

1) There is something wrong with your nrfutil application.

2) There is something wrong with how you are generating your package.

Have you tried this command with one of the example ZIP files provided with the SDK?  Also, what command are you using to generate the package?

[retrostately]

Also, your version of nrfutil is probably fine.  But if you want to try building it from source, you can do the following:

mkdir nrfutil
cd nrfutil
git clone https://github.com/NordicSemiconductor/pc-nrfutil.git .
pip2 install -r requirements.txt
pip2 install pyinstaller
pyinstaller nrfutil.spec

This assumes you have Python 2.x and git installed. After this, it will produce an nrfutil.exe file in the 'dist' folder.  You can move it wherever you want.  Just make sure that directory is in your PATH variable before the Python path listing (otherwise it will run the version of nrfutil you installed via pip).  Again, I doubt the nrfutil is the problem, but it's worth a shot.

Also, it would help if you explained a bit more about the setup.  So, you have your nRF connectivity device connected to the COM port with the connectivity firmware flashed to it.  What about the target device?  Is it also a PCA10040?  Does it already have a DFU bootloader flashed to it?  Is it a custom bootloader or did you flash a sample from the SDK to it?  Are you signing the ZIP package with the correct key?  Some more details would be helpful.

[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

[Yosi.stx]

Hello,

I do have 2 EVBs, but one is PCA10040 (nrf52) and the other is PCA10028 (nrf51).

For trying your files, can I use the PCA10028 as the connectivity board and the PCA10040 as the target board?

My Segger JLink version is "JLink_V620i".

The Segger JLink version is OK, since both of the EVBs work fine as connectivity boards when I work with the "nRF Connect v2.3.0" running on my PC (see attached figures).

PCA10040  as connectivity board:

PCA10028 as connectivity board:

In both cases I can perform successful secure DFU with many ZIP packages that I have created.

The only problem is with the nrfutil when used as DFU controller.