When I run nrfutil dfu genpkg and do not feed a key file, the python crashes at line 238 of dfu/package.py with "AttributeError: 'Package' object has no attribute 'key_file'" on the line that reads "signer.load_key(self.key_file)"

Please advise!

I think it would be favorable if the displayed hash has the same byte order than e.g. the output of sha256sum.

Example:

$ sha256sum application.bin
f80c246f0dc114c0e46886bc81955c606535e0931ca822c28d07b54f3e73c85a *application.bin

$ nrfutil pkg display test_DFU.zip

DFU Package: <test_DFU.zip>:
|
|- Image count: 1
|
|- Image #0:
   |- Type: application
   |- Image file: application.bin
   |- Init packet file: application.dat
      |
      |- op_code: INIT
      |- signature_type: ECDSA_P256_SHA256
      |- signature: a1ec4ea1bc017e50f7aceac888fdfd89873207a38cf25f5bc8a50a934802b1184e16ac7549cb4e1f8625843bdfd573d84c311289c55721e39db766c81cd014c7
      |
      |- fw_version: 0x00000001 (1)
      |- hw_version 0x00000034 (52)
      |- sd_req: 0x8C
      |- type: APPLICATION
      |- sd_size: 0
      |- bl_size: 0
      |- app_size: 60812
      |
      |- hash_type: SHA256
      |- hash: 5ac8733e4fb5078dc222a81c93e03565605c9581bc8668e4c014c10d6f240cf8
      |
      |- is_debug: False

using python 2.7.11, running OS X El Capitan 10.11.4.

error.txt
There is a race condition in DfuTransportBle with debugger log enable
For example if we run nrfutil for combination zip file SD+BL+APP
nrfutil -vv dfu ble -ic NRF51 -pkg sd_bl_app_s132.zip -p COM104 -n "DfuTarg" -f

1. It will first start and do sending firmware of SD+BL and finish successfully
2. When it start reconnect to the new BL to continue sendind APP, the service discovery step will be failed with error: None object does not have (__getitem__)

Hi ! I'm having a problem using the Serial DFU :/

Here is my setup :

• NRF52840 DK
• Softdevice SDK14 V5.0.0
• nrfutil v3.2.1
• OSX Sierra

I am using the bootloader_secure_serial from SDK14 examples

The public and private keys where set.

1. I erase all (nrfjprog -f nrf52 --eraseall)
2. I flash the softdevice (nrfjprog -f nrf52 --program s140_nrf52840_5.0.0-2.alpha_softdevice.hex --sectorerase)
3. I flash the bootloader (nrfjprog/nrfjprog -f nrf52 --program nrf52840_bootloader_s140.hex --sectorerase)
4. I connect my RTTViewer

Here is what I see :

<info> nrf_sdh: Inside main
<debug> nrf_sdh: In nrf_bootloader_init
<debug> nrf_sdh: in weak nrf_dfu_init_user
<debug> nrf_sdh: In real nrf_dfu_init
<debug> nrf_sdh_soc: Running nrf_dfu_settings_init(sd_irq_initialized=false).
<debug> nrf_dfu_settings: Calling nrf_dfu_flash_init(sd_irq_initialized=false)...
<debug> nrf_dfu_settings: Initializing nrf_fstorage_nvmc backend.
<debug> nrf_sdh: Initializing the clock.
<debug> nrf_sdh: Enter nrf_dfu_continue
<error> nrf_sdh: Single: Invalid bank
<debug> nrf_sdh: Enter nrf_dfu_app_is_valid
<debug> nrf_sdh: Return false in valid app check
<debug> nrf_sdh: In nrf_dfu_transports_init
<debug> nrf_sdh: num transports: 1
<debug> nrf_sdh: UART initialized
<debug> nrf_sdh: After nrf_dfu_transports_init
<debug> nrf_dfu_settings: Calling nrf_dfu_flash_init(sd_irq_initialized=false)...
<debug> nrf_dfu_settings: Initializing nrf_fstorage_nvmc backend.
<debug> nrf_sdh: Waiting for events

5. I package my application (nrfutil pkg generate --application nrf52840_hid_keyboard.hex --key-file private.pem app_dfu_package.zip --debug-mode)
6. And finally I try to perform serial dfu (nrfutil dfu serial -pkg app_dfu_package.zip -p /dev/tty.usbmodem1421)

RTT Viewer

<debug> nrf_sdh: Received ping 1
<debug> nrf_sdh: Sending Response: [0x9, 0x1]
<debug> nrf_sdh: Set receipt notif
<debug> nrf_sdh: Sending Response: [0x2, 0x1]
<debug> nrf_sdh: Received get serial mtu
<debug> nrf_sdh: Sending Response: [0x7, 0x1]

And finally the error from nrfutil

 [------------------------------------]    0%
Traceback (most recent call last):
  File "/usr/local/bin/nrfutil", line 9, in <module>
    load_entry_point('nrfutil==3.3.0', 'console_scripts', 'nrfutil')()
  File "/Library/Python/2.7/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/Library/Python/2.7/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/Library/Python/2.7/site-packages/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/Library/Python/2.7/site-packages/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/Library/Python/2.7/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/Library/Python/2.7/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/Library/Python/2.7/site-packages/nrfutil-3.3.0-py2.7.egg/nordicsemi/__main__.py", line 655, in serial
    dfu.dfu_send_images()
  File "/Library/Python/2.7/site-packages/nrfutil-3.3.0-py2.7.egg/nordicsemi/dfu/dfu.py", line 122, in dfu_send_images
    self._dfu_send_image(self.manifest.application)
  File "/Library/Python/2.7/site-packages/nrfutil-3.3.0-py2.7.egg/nordicsemi/dfu/dfu.py", line 90, in _dfu_send_image
    self.dfu_transport.send_init_packet(data)
  File "/Library/Python/2.7/site-packages/nrfutil-3.3.0-py2.7.egg/nordicsemi/dfu/dfu_transport_serial.py", line 239, in send_init_packet
    self.__stream_data(data=init_packet)
  File "/Library/Python/2.7/site-packages/nrfutil-3.3.0-py2.7.egg/nordicsemi/dfu/dfu_transport_serial.py", line 405, in __stream_data
    response = self.__calculate_checksum()
  File "/Library/Python/2.7/site-packages/nrfutil-3.3.0-py2.7.egg/nordicsemi/dfu/dfu_transport_serial.py", line 347, in __calculate_checksum
    (offset, crc) = struct.unpack('<II', bytearray(response))
TypeError: 'NoneType' object is not iterable

I saw somebody else having the same problem in a comment here, but there was no answer to this specific issue : Nordic Dev Zone

I'm trying to generate a package for an application compiled with SDK11.
The package fails to upload (error message saying "Upload failed: REMOTE DFU operation failed")
Looking at the zip file, and comparing its contents with the examples provided along with SDK11, I see that it completely missing the following information from the json manifest:

init_packet_data": {
"application_version": 4294967295,
"device_revision": 65535,
"device_type": 65535,
"firmware_crc16": 9581,
"softdevice_req": [
65534
]
}
},
"dfu_version": 0.5

It only contains the entries for
"bin_file": "nrf51422_xxac_s130.bin",
"dat_file": "nrf51422_xxac_s130.dat",

Any ideas what is going on?
I'm running:
(workspace) C:\yotta\tmp>nrfutil pkg generate --application nrf51422_xxac_s130.h
ex --key-file mykey.pem --sd-req 0x80 output.zip

This is reproducible in both osx and windows.
nrfutil version is 1.3.2

Running nrfutil dfu thread -pkg /tmp/Thread_DFU-test/app_dfu_package.zip --port /dev/ttyACM0 (without -f) in my Debian box fails consistently with the following error stack:

Traceback (most recent call last):
  File "/home/ivan/devel/pc-nrfutil/nordicsemi/__main__.py", line 918, in thread
    transport.open()
  File "/usr/local/lib/python2.7/dist-packages/nordicsemi/thread/tncp.py", line 208, in open
    raise Exception('Failed to reset NCP. Please flash connectvity firmware.')
Exception: Failed to reset NCP. Please flash connectvity firmware.

This is particularly annoying, since I did run a nrfutil dfu thread -f ... just a few seconds earlier (just to find a different error).

Is there any way to check the serialized softdevice messages and check what's going on? Reflashing the connectivity firmware obviously doesn't help.

The README states that version 1.0 (default in master) of this tool only supports nRF SDK 11.1 and later. Am I mistaken in that nRF SDK 11.0 is the latest public release?

To avoid confusion, perhaps the "modern" version should be moved to a development branch rather than master. Or specify in the README that the tool targets an unreleased version of the nRF SDK.

Thanks for your work on this!

In the event that a file already exists, an nrfutil operation which would overwrite the file will pause and query the user before doing so "File found at filename. Do you want to overwrite the file? [y/N]". In Cygwin nrfutil will still pause, but the message is not displayed. To the user it seems nrfutil has crashed.

To reproduce this issue, open a cygwin and execute the following commands:

nrfutil keys generate private.pem
nrfutil keys generate private.pem

Some app files (sample attached) cause "nrfutil settings generate" to go into an infinite loop. Can nearly even crash Linux--machine runs slowly, and running "top" in another terminal shows nrfutil using all of ram.

I suspect it's because this hex file contains a flash section at 0x23000 and a ram section at 0x20002180. But even if it's naively allocating a single large buffer, that's only half a gig (is my math right on that?). Doesn't seem like that should stress my 16GB box.

base.hex.gz

Dear Team,

the doc says,

nrfutil keys display --key sk --format code private_key.pem 

should be used to convert the private key for usage in code, but the above error message is shown. Is this intended?

Due to the fact that apple includes "six" in a directory protected by SIP :
the instructions should be. revised for:
Installing from PyPI

To install the latest published version from the Python Package Index simply type:

pip install --ignore-installed six nrfutil

Hi,

I'm a bit confused regarding the SDK versions. In the versions section, you mention that there are two ways of generating firmware packages. One for SDK <= v11.0 and one for SDK >= v11.1.

But when I look for the SDK at download pages, I can only find the v11.0? Would you mind explaining what am I missing? Likewise I can only find documentation up to v11.0 at the documentation pages.

When I run the the nrfutil application without nrfutil installed I get the following error:

$ python nordicsemi/__main__.py
Traceback (most recent call last):
  File "nordicsemi/__main__.py", line 39, in <module>
    from nordicsemi.thread.dfu_server import ThreadDfuServer
ImportError: No module named nordicsemi.thread.dfu_server

This doesn't happen when I have nrfutil installed on the system. (I guess it that uses the installed files?)

Setup

• Python: 2.7
• OS: GNU/Linux - Fedora 26
• Latest master checkout (2de577f)

Steps to reproduce

• Make sure nrfutil is not installed on the system (Global or local)
• run python nordicsemi/__main__.py in the root of the pc-nrutil repo

Running nrfutil dfu thread -pkg /tmp/Thread_DFU-test/app_dfu_package.zip --port /dev/ttyACM0 -f in my Debian box fails consistently with the following error stack:

Address not specified. Using ff03::1 (all Thread nodes)
Using connectivity board at serial port: /dev/ttyACM0
Board already flashed with connectivity firmware.
Opening serial to /dev/ttyACM0 @ 115200
2017-11-10 16:55:45,473 Failed to set property PROP_IPv6_ICMP_PING_OFFLOAD
Traceback (most recent call last):
  File "/home/ivan/devel/pc-nrfutil/nordicsemi/__main__.py", line 918, in thread
    transport.open()
  File "/usr/local/lib/python2.7/dist-packages/nordicsemi/thread/tncp.py", line 211, in open
    if (not self._attach_to_network()):
  File "/usr/local/lib/python2.7/dist-packages/nordicsemi/thread/tncp.py", line 102, in _attach_to_network
    self._set_property(*props)
  File "/usr/local/lib/python2.7/dist-packages/nordicsemi/thread/tncp.py", line 87, in _set_property
    raise Exception("Failed to set property {}".format(self.__class__._propid_to_str(propid)))
Exception: Failed to set property PROP_IPv6_ICMP_PING_OFFLOAD

On one hand, I'd like the DFU procedure to just succeed. All my attempts to run nrfutil dfu thread -f on Debian fail with this error

On the other hand, as a user, I'd like to see a more meaningful error message - what is PROP_IPv6_ICMP_PING_OFFLOAD and why should I care about it, what should I do to fix that?

Is this error caused by some failure at initializing something more general (e.g. sending the first IP packet)? If there is a root cause for this, I'd like to see it in the error message.

Got this error:
Downloading/unpacking pyspinel (from nrfutil==3.0.0)
Could not find a version that satisfies the requirement pyspinel (from nrfutil==3.0.0) (from versions: 1.0.0a1)

Hello,

I'm able to successfully run nrfutil using python, but I'm having a little trouble when running my own compiled nrfutil.exe. Here's my traceback:

V:\Code\Firmware\pc-nrfutil-master\0.3.0>nrfutil.exe
Traceback (most recent call last):
File "main.py", line 32, in
File "zipextimporter.pyc", line 82, in load_module
File "click__init__.pyc", line 18, in
File "zipextimporter.pyc", line 82, in load_module
File "click\core.pyc", line 7, in
File "zipextimporter.pyc", line 82, in load_module
File "click\types.pyc", line 4, in
File "zipextimporter.pyc", line 82, in load_module
File "click_compat.pyc", line 530, in
File "zipextimporter.pyc", line 82, in load_module
File "click_winconsole.pyc", line 23, in
File "ctypes__init__.pyc", line 378, in getattr
File "ctypes__init__.pyc", line 383, in getitem
AttributeError: function 'PyObject_GetBuffer' not found

Seems NRFUTIL_VERSION = "0.3.0" is not updated.

When using pc-nrfutil for dfu update and running on linux:
After dfu finished, in case of exception, or error nrfutil continue running users needs to use kill -9 to kill the process.

Please refer to this thread on the forum. It lists up some valid points on why it would be nice to have nrfutil.exe included in the release.

nrfutil keys generate private.pem
doesn't workanymore

nrfutil keys --gen-key private.pem
is the correct command line parameter. Please update the docs.

I'm on Mac OSX 10.11, using Python installed from www.python.org, and using master of this project.

$ python --version
Python 2.7.12

$ pip --version
pip 8.1.2 from /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages (python 2.7)

$ sudo -H python setup.py install
[installs with no errors]

Because of this issue in Google's protobuf protocolbuffers/protobuf#737, I modify the perms on one of protobuf's directories with sudo chmod 644 /Library/Python/2.7/site-packages/protobuf-3.0.0-py2.7.egg/EGG-INFO/*

$ nrfutil --help
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/bin/nrfutil", line 9, in <module>
    load_entry_point('nrfutil==1.4.5', 'console_scripts', 'nrfutil')()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 357, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 2394, in load_entry_point
    return ep.load()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 2108, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nrfutil-1.4.5-py2.7.egg/nordicsemi/__main__.py", line 47, in <module>
    from nordicsemi.dfu.dfu import Dfu
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nrfutil-1.4.5-py2.7.egg/nordicsemi/dfu/dfu.py", line 47, in <module>
    from nordicsemi.dfu.package         import Package
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nrfutil-1.4.5-py2.7.egg/nordicsemi/dfu/package.py", line 52, in <module>
    from nordicsemi.dfu.init_packet_pb import *
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nrfutil-1.4.5-py2.7.egg/nordicsemi/dfu/init_packet_pb.py", line 37, in <module>
    import dfu_cc_pb2 as pb
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nrfutil-1.4.5-py2.7.egg/nordicsemi/dfu/dfu_cc_pb2.py", line 42, in <module>
    from google.protobuf.internal import enum_type_wrapper
ImportError: cannot import name enum_type_wrapper

Is this something to do with the version of protobuf you're using?

Running nrfutil.py standalone will give me some help:

$ python nrfutil.py 
Usage:  [OPTIONS] COMMAND [ARGS]...

Options:
  -v, --verbose            Show verbose information.
  -o, --output <filename>  Log output to file
(etc)

Same happens when I'm missing a command:

$ python nrfutil.py dfu
Usage: dfu [OPTIONS] COMMAND [ARGS]...

  This set of commands supports Device Firmware Upgrade procedures over both
  BLE and serial transports.

Options:
  --help  Show this message and exit.

Commands:
  ble         Update the firmware on a device over a BLE connection.
(etc)

Note that the output of nrfutil dfu is the same as nrfutil dfu --help

However, when missing a required parameter, the output is different:

$ python nrfutil.py dfu serial
Usage: dfu serial [OPTIONS]

Error: Missing option "-pkg" / "--package".

That's not really useful.

Compare with the output of nrfutil.py dfu serial --help, which is what I would expect. Note how information about required fields is there to help me.

$ python nrfutil.py dfu serial --help
Usage: dfu serial [OPTIONS]

  Perform a Device Firmware Update on a device with a bootloader that
  supports serial DFU.

Options:
  -pkg, --package PATH            Filename of the DFU package.  [required]
(etc)

I've been testing serial DFU with an customized version from branch 0.5.1 which supports recording the packet output stream. It appears there may be a defect related to packet sequence numbering for the case where the DFU ZIP file used for the DFU update contains more than one image.

For example, if nrfutil is first used to build a DFU ZIP file containing bootloader, softdevice, and application, then the resulting file contains two images: 1) a BL+SD image, and 2) an APP image.

If this same DFU ZIP file is provided to nrfutil to initiate a serial DFU, the serial transport does not reset the packet sequence number between sending the two images. This results in a somewhat "random" staring sequence number for the second image (depending on how many packets are in the first image modulus 8). In my case, I was producing two HCI packet recording files which I then replay to a serial bootloader, but the second one never was accepted correctly since it didn't begin with sequence 1. I corrected the problem by setting the HCiPacket.sequence_number = 0 within the serial transport open() function. (Maybe close would have been a better location, I'm not sure.) In any case, that produced two recording files where both of them have sequence 1 for the first packet and that seems to work.

On my Ubuntu (Xenial) box, "pip install nrfutil" installs version 0.3.0.

I'm getting the following error message:

nrfutil dfu genpkg respeck.zip --application _build/nrf51822_xxaa_s110.hex --application-version 0xffff --dev-revision 0xffff --dev-type 0xffff --sd-req 0xfffe
Traceback (most recent call last):
File "/Users/janek/Library/Python/2.7/bin/nrfutil", line 9, in
load_entry_point('nrfutil==0.3.0', 'console_scripts', 'nrfutil')()
File "/Library/Python/2.7/site-packages/click/core.py", line 700, in call
return self.main(_args, *_kwargs)
File "/Library/Python/2.7/site-packages/click/core.py", line 680, in main
rv = self.invoke(ctx)
File "/Library/Python/2.7/site-packages/click/core.py", line 1027, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/Library/Python/2.7/site-packages/click/core.py", line 1027, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/Library/Python/2.7/site-packages/click/core.py", line 873, in invoke
return ctx.invoke(self.callback, *_ctx.params)
File "/Library/Python/2.7/site-packages/click/core.py", line 508, in invoke
return callback(_args, **kwargs)
File "/Users/janek/Library/Python/2.7/lib/python/site-packages/nrfutil-0.3.0-py2.7.egg/nordicsemi/main.py", line 236, in genpkg
package.generate_package(zipfile_path)
File "/Users/janek/Library/Python/2.7/lib/python/site-packages/nrfutil-0.3.0-py2.7.egg/nordicsemi/dfu/package.py", line 220, in generate_package
init_packet = self._create_init_packet(firmware)
File "/Users/janek/Library/Python/2.7/lib/python/site-packages/nrfutil-0.3.0-py2.7.egg/nordicsemi/dfu/package.py", line 320, in _create_init_packet
return p.generate_packet()
File "/Users/janek/Library/Python/2.7/lib/python/site-packages/nrfutil-0.3.0-py2.7.egg/nordicsemi/dfu/init_packet.py", line 79, in generate_packet
format_string = self.__generate_struct_format_string()
File "/Users/janek/Library/Python/2.7/lib/python/site-packages/nrfutil-0.3.0-py2.7.egg/nordicsemi/dfu/init_packet.py", line 97, in __generate_struct_format_string
for key in sorted(self.init_packet_fields.keys(), key=lambda x: x.value):
File "/Users/janek/Library/Python/2.7/lib/python/site-packages/nrfutil-0.3.0-py2.7.egg/nordicsemi/dfu/init_packet.py", line 97, in
for key in sorted(self.init_packet_fields.keys(), key=lambda x: x.value):
AttributeError: 'int' object has no attribute 'value'

When installing nrfutil 0.5.2 using

pip install nrfutil==0.5.2

the requirements listed in requirements.txt do not get installed. This is because setup.py does not seem to install them.

Related to issue #65.

I have few puck.js devices (it is nRF52 based board) and want to update firmware. I have not any Android 6 device so I can not use Android tools (I've checked all phones I can access - nRF tools not supported).
At the same time, I have few linux boards with BLE supported. I can see my puck.js devices, for example:
hcitool lescan
LE Scan ...
DC:0F:DF:1E:D4:73 DfuTarg
I'd want to update nRF firmware using the linux board. Is it possible?
Unfortunately, Python is not in my skills. I'm mostly low-level programmer (and so I can connect puck.js to JTAG/SWD and update firmware - but it seems to be ugly way).

It would be great if this is available as standard pip package?
Any plan of doing that?

As stated in the README version 0.5.2 of this tool needs to be installed in order to build packages for the legacy DFU system. However, the latest version <= version 0.5.2 that can installed using pip is version 0.3.0.

Since mbed-os still comes with the legacy DFU bootloader I think a lot of people (including me) still use the legacy DFU package format. It would be nice if a more recent version (i.e version 0.5.2) of the tool that supports the legacy DFU package format could be installed using pip.

The list of SoftDevice firmware IDs is not up to date. This information is required when working with DFU.
The list currently looks like this:
|s130_nrf51_1.0.0|0x67|
|s130_nrf51_2.0.0|0x80|
|s132_nrf52_2.0.0|0x81|
|s130_nrf51_2.0.1|0x87|
|s132_nrf52_2.0.1|0x88|
|s132_nrf52_3.0.0|0x8C|

I'm not certain if PB2 and PB3 (the used versions) are compatible, if they are, it should be stated. If they are not, it should be stated explicitly which version should be used.

I think its PB2 due to the name of the generated file "dfu_cc_pb2.py".

Please make it compatible with Python3.

Getting hard Python crashes when trying to run a DFU BLE command using nrfutil.

Sample command:
nrfutil dfu ble -ic NRF51 -pkg dfu_test_app_hrm_s132.zip -n "DfuTest"

Return:
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6

All versions of PIP, Python & nrfutil are up to date and freshly installed as of 02 Feb 2017. Running MacOS 10.12.3 Beta (16D30a).

Any ideas how to resolve?

I am not sure of use of this message - the filename is already known to the user.
When using the tool with parallel makefiles getting this message does not make sense.

Although it is easy to disable it by redirecting the output to /dev/null, it would be good to get it fixed in the tool itself.

Is it possible to show this message only if --verbose is specified.
Another option is --silent to suppress this message.

If needed I can submit a patch.

Update new version 2.2.0 -> 2.3.0 since we have bug fix for serial dfu support PING CMD and update on https://pypi.python.org/pypi/nrfutil

The "Hardware setup" link in README does not work:

Note: To use the dfu ble option you will need to set up your boards to be able to communicate with your computer. You can find additional information here: Hardware setup.

nrtutils.spec, line 14:
Master uses \ instead of / in two places, which causes the search for nodicsemi/main.py to fail on linux.

Also, pyinstaller fails unless the whole path to nrfutils.spec is given, not just the relative path. So the instructions should show:
pyinstaller /whole/path/here/nrfutils.spec

Serial DFU could fail if bootloader board is not ready when trying to ping. This could happen during a combined DFU.

In dfu_transport_serial.py in open() the bootloader board is pinged twice.
If the first __ping() fails the complete DFU operation fails. It looks like the first __ping() should be removed.

Also, when looking into the __ping() function, I see that instead of returning an error code, it will raise an exception when the bootloader board is not responding. This will break the "waiting for ping"-functionality in open().

Using version 5a5e418 with pc-ble-driver-py version 0.4.0, the following happens when attempting to perform a DFU over BLE with auto-flashing of the connectivity driver:

mypath>nrfutil dfu ble -f -p COM40 -pkg app_v1.0.0.zip
No target selected. Default device name: DfuTarg is used.
  [------------------------------------]    0%

Failed to update the target. Error is:

Hello,

I have issue to run nrfutil of version 2.3.0 with dfu ble feature.

I compiled sources like boost (in 32 mode), pc-driver-ble-py(with 32 toolchain)

After compilation pc-driver-ble-py seems to work good, examples of advertisement working.
The main problem is with dfu ble feature. The device have bootloader from SDK 12.0 with custom fixing of using higher softdevice 3.1.0. The custom bootloader working properly with nrf connect desktop but not working with nrfutil ver 2.3

There is possibility that app nrf connect can handle with older sdk bootloader and nrfutil not?
Below is output from nrfutil.

No target selected. Default device name: DfuTarg is used.
Please select connectivity serial port:
0 : COM6 - 681706210
Enter your choice: : 0
Board already flashed with connectivity firmware.
[------------------------------------] 0%
Traceback (most recent call last):
File "nordicsemi_main_.py", line 702, in
File "site-packages\click-6.7-py2.7.egg\click\core.py", line 722, in call
File "site-packages\click-6.7-py2.7.egg\click\core.py", line 697, in main
File "site-packages\click-6.7-py2.7.egg\click\core.py", line 1066, in invoke
File "site-packages\click-6.7-py2.7.egg\click\core.py", line 1066, in invoke
File "site-packages\click-6.7-py2.7.egg\click\core.py", line 895, in invoke
File "site-packages\click-6.7-py2.7.egg\click\core.py", line 535, in invoke
File "nordicsemi_main_.py", line 688, in ble
File "nordicsemi\dfu\dfu.py", line 122, in dfu_send_images
File "nordicsemi\dfu\dfu.py", line 83, in _dfu_send_image
File "nordicsemi\dfu\dfu_transport_ble.py", line 231, in open
File "nordicsemi\dfu\dfu_transport_ble.py", line 336, in __set_prn
File "nordicsemi\dfu\dfu_transport_ble.py", line 427, in __get_response
pc_ble_driver_py.exceptions.NordicSemiException: No Response: 0xFD
Failed to execute script main
f:\dd\vctools\crt\crtw32\stdcpp\thr\mutex.c(51): mutex destroyed while busy

When doing a DFU of a combined SD + APP image, after the SD update, nrfutil should re-connect to the bootloader to do the APP update. However, I've experienced cases where nrfutil re-connects to other BLE-devices nearby, and the DFU fails.
I've debugged and found the cause of this issue.

When doing the SD update:

In the class DFUAdapter, when connect() is called, the parameters "target_device_name" and "target_device_addr" are given and stored in the class instance.
Upon receiving advertisement reports, the target_device values are compared to the BLE address and BLE device name of the advertising device. If one of them match nrfutil will initiate a connection.

However, DFUAdapter keeps getting advertisement reports until the connection is successfully completed. In some occasions it is possible to get advertisement packets without a BLE device name.
Here is a short log from a connection:

BLE: connect: target address: 0xNone, target name: DfuTest
BLE: Scanning...
Received advertisement report, address: 0xDCF79209A18C, device_name: DfuTest
BLE: Found target advertiser, address: 0xDCF79209A18C, name: DfuTest
BLE: Connecting to 0xDCF79209A18C
Received advertisement report, address: 0xDCF79209A18C, device_name:
BLE: Found target advertiser, address: 0xDCF79209A18C, name:
BLE: Connecting to 0xDCF79209A18C
BLE: Connected to <pc_ble_driver_py.ble_driver.BLEGapAddr object at 0x059929B0>
BLE: Connected to target
BLE: Service Discovery

From these lines of log and by looking at the code, we can now see that the value of self.target_device_name is an empty string.

When doing the following APP update:

The empty string stored for self.target_device_name will be an issue when we try to re-connect to the bootloader after the SD update is succeeded.
This is because nrfutil will connect to a device with an empty BLE device name (empty string).

FIX

In the on_gap_evt_adv_report() in DFUAdapter():
Remove the line: self.target_device_name = dev_name

The sd-req value for the latest softdevice is missing:

The Latest release of SD is s132_nrf52_4.0.2_softdevice.hex and the latest capable release that nrfutil can handle is s132_nrf52_4.0.0_softdevice.hex. this renders nrfutil broken for the latest softdevice.

I tested with the value for s132_nrf52_4.0.0_softdevice.hex (0x95) just in case but no, it really needs the right value.

Please make sure to synchronize your release in the future. Thanks.

When installing version 0.3 on a mac I got an error message when running "python setup.py install" saying that "setuptools_behave is missing".

This was fixed by adding a dependency to the "behave" package in requirements.txt.

nrfutil crashes if the private key file is not found. The error from python is readable enough to understand what happened, but a single line like "File not found: private.pem" would be better.

Copy-paste from console when triggering the error:

$ nrfutil keys display --key pk --format code --out_file dfu_public_key.c private.pem

Traceback (most recent call last):
  File "C:\Python27\Scripts\nrfutil-script.py", line 9, in <module>
    load_entry_point('nrfutil==1.4.16', 'console_scripts', 'nrfutil')()
  File "C:\Python27\lib\site-packages\click\core.py", line 716, in __call__
    return self.main(*args, **kwargs)
  File "C:\Python27\lib\site-packages\click\core.py", line 696, in main
    rv = self.invoke(ctx)
  File "C:\Python27\lib\site-packages\click\core.py", line 1060, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "C:\Python27\lib\site-packages\click\core.py", line 1060, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "C:\Python27\lib\site-packages\click\core.py", line 889, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "C:\Python27\lib\site-packages\click\core.py", line 534, in invoke
    return callback(*args, **kwargs)
  File "C:\Python27\lib\site-packages\nordicsemi\__main__.py", line 264, in display
    raise NordicSemiException("File not found: %s" % key_file)
pc_ble_driver_py.exceptions.NordicSemiException: File not found: private.pem

In case the auto-detection fails

Using version 1.1.1 from pip the following error occurs when trying to create a DFU zip package:

mypath>nrfutil pkg generate --application app.hex --key-file nist.pem --application-version 10000 app_v1.0.0.zip

File "C:\Python276-64\lib\site-packages\nrfutil-1.1.1-py2.7.egg\nordicsemi\__main__.py", line 262, in generate package.generate_package(zipfile_path) File "C:\Python276-64\lib\site-packages\nrfutil-1.1.1-py2.7.egg\nordicsemi\dfu\package.py", line 212, in generate_package Package.normalize_firmware_to_bin(work_directory, firmware_data[FirmwareKeys.FIRMWARE_FILENAME]) File "C:\Python276-64\lib\site-packages\nrfutil-1.1.1-py2.7.egg\nordicsemi\dfu\package.py", line 352, in normalize_firmware_to_bin firmware_filename = os.path.basename(firmware_path) File "C:\Python276-64\lib\ntpath.py", line 198, in basename return split(p)[1] File "C:\Python276-64\lib\ntpath.py", line 170, in split d, p = splitdrive(p) File "C:\Python276-64\lib\ntpath.py", line 125, in splitdrive if p[1:2] == ':': TypeError: 'int' object has no attribute '__getitem__'

This error occurs since the arguments passed to "__add_firmware_info" is in the wrong order.

Hi, this is Zou the Nordic Japan FAE reporting below issue.

• JLink_Linux_V612i_x86_64
• nRF5x-Command-Line-Tools_9_3_1_Linux-x86_64
• nrfutil v2.1.0
  Using nRF51 dongle as connectivity IC, firmware is as below
  /usr/local/lib/python2.7/dist-packages/pc_ble_driver_py/hex/sd_api_v2/connectivity_1.0.1_1m_with_s130_2.0.1.hex

nrfutil dfu ble -ic NRF51 -pkg app_dfu_v1.1.zip -p /dev/ttyACM0 -n "DfuTarg"
OR
nrfutil dfu ble -ic NRF51 -pkg app_dfu_v1.1.zip -p /dev/ttyACM0 -a DF:AF:6F:7A:0D:82

Result:
[------------------------------------] 0%
Traceback (most recent call last):
File "/usr/local/bin/nrfutil", line 11, in
sys.exit(cli())
File "/usr/local/lib/python2.7/dist-packages/click/core.py", line 722, in call
return self.main(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python2.7/dist-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python2.7/dist-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python2.7/dist-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python2.7/dist-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/nordicsemi/main.py", line 660, in ble
dfu.dfu_send_images()
File "/usr/local/lib/python2.7/dist-packages/nordicsemi/dfu/dfu.py", line 122, in dfu_send_images
self._dfu_send_image(self.manifest.application)
File "/usr/local/lib/python2.7/dist-packages/nordicsemi/dfu/dfu.py", line 83, in _dfu_send_image
self.dfu_transport.open()
File "/usr/local/lib/python2.7/dist-packages/nordicsemi/dfu/dfu_transport_ble.py", line 223, in open
self.dfu_adapter.open()
File "/usr/local/lib/python2.7/dist-packages/nordicsemi/dfu/dfu_transport_ble.py", line 87, in open
self.adapter.driver.open()
File "/usr/local/lib/python2.7/dist-packages/wrapt/wrappers.py", line 561, in call
args, kwargs)
File "/usr/local/lib/python2.7/dist-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

Could you tell me what's wrong in above setup?
Please add Linux-environment DFU BLE test sample to "nrfutil_v1.1.pdf", too.

Hi!
I have an nRF52 evaluation board which I want to test DFU upgrade over serial on.

Since I'm using SDK 11, I'm checking out branch 0_5_1.

In README.md it is stated "Note: DFU over a serial line is currently disabled". Is this true? Then what exactly is this project for? The nrfutil command line tool doesn't say anything that it shouldn't work.

I'm flashing SoftDevice s132 2.0.1 and I've tried both examples/dfu/bootloader/pca10040/single_bank_serial_s132/armgcc and examples/dfu/bootloader/pca10040/dual_bank_serial_s132/armgcc, but I can't get the tool to work. I get this:

nrfutil dfu serial --package ../dfu_test_app_hrm_s132.zip -p /dev/ttyACM0  --flowcontrol --baudrate 38400
Upgrading target on /tmp/ser with DFU package /root/dfu_test_app_hrm_s132.zip. Flow control is enabled.
  [------------------------------------]    0%Timed out waiting for acknowledgement from device.


Failed to upgrade target. Error is: No data received on serial port. Not able to proceed.

When sniffing on the serial communication using socat, I get:

[root@XXX ~]# socat -d -v -x PTY,link=/tmp/ser,wait-slave,raw /dev/ttyACM0,raw
> 2016/07/05 15:00:27.776812  length=28 from=0 to=27
 c0 d1 4e 01 e0 03 00 00 00 04 00 00 00 00 00 00  ..N.............
 00 00 00 00 00 e0 4b 00 00 dd c6 c0              ......K.....
--

Thanks, Jacob