nrfutil with the builtin BLE interface?

RE: nrfutil with the builtin BLE interface?

sfrank — Wed, 29 Apr 2020 14:17:00 GMT

Hello! The os_ble branch is currently in a rather dirty state and commands not implemented. You can try the following:

```

cd pc-nrfutil

python3 nordicsemi/bleak_dfu_cli.py $DFU_ADDR $NRF_ZIP_PKG_PATH

```

where `$DFU_ADDR` is the BLE address (assumes device already in DFU.)
you also might need to append `pwd` to PYTHONPATH.

RE: nrfutil with the builtin BLE interface?

Mimmo — Mon, 27 Apr 2020 14:58:37 GMT

Hi,

I am also interested to have nrfutil running with native BLE on Linux, on my MAC that use BCM2046 running Ubuntu 18.04 and on my raspberry that use Debian Buster.

On both the bluetooth interface available is hci0.

I installed your pc-nrfutil (os_ble-6.1.0) branch on my linux but I have some questions:

which is the port that need to be used on nrfutil command?

Bluetooth is associated the hci0 interface. If i run the command:

nrfutil -v dfu ble -ic NRF52 -a "D2B307388F02" -p hci0 -pkg pkg_app_v1_1_5.zip

Traceback (most recent call last):
File "/usr/local/bin/nrfutil", line 8, in <module>
    sys.exit(cli())
File "/usr/local/lib/python3.6/dist-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
File "/usr/local/lib/python3.6/dist-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
File "/usr/local/lib/python3.6/dist-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.6/dist-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.6/dist-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.6/dist-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
File "/usr/local/lib/python3.6/dist-packages/nordicsemi/__main__.py", line 1155, in ble
    is_jlink = port_is_jlink(port)
File "/usr/local/lib/python3.6/dist-packages/nordicsemi/__main__.py", line 1092, in port_is_jlink
    raise NordicSemiException('Board not found')
pc_ble_driver_py.exceptions.NordicSemiException: Board not found

If I run the command using the nrf52840 dongle, it works fine:

nrfutil -v dfu ble -ic NRF52 -a "D2B307388F02" -p /dev/ttyACM0 -pkg pkg_app_v1_1_5.zip

Thanks for any sugestions

RE: nrfutil with the builtin BLE interface?

tesc — Mon, 17 Feb 2020 16:19:17 GMT

Hi,

Thank you for sharing!

Regards,
Terje

RE: nrfutil with the builtin BLE interface?

sfrank — Sun, 16 Feb 2020 10:29:41 GMT

If this is of interest to anyone you can follow the progress here: https://github.com/5frank/pc-nrfutil in the branch 'os_ble'.

I just made a successful DFU upgrade on linux. The BLE lib used is crossplattform so should work on windows and MacOS but this not (yet) tested.

RE: nrfutil with the builtin BLE interface?

tesc — Wed, 12 Feb 2020 13:25:49 GMT

HI,

I see. For BLE transport for DFU, nrfutil builds on pc-ble-driver-py, which is serialization of our SoftDevice (BLE stack.) Therefore what you see is the SoftDevice API.

Regards,
Terje

RE: nrfutil with the builtin BLE interface?

sfrank — Tue, 11 Feb 2020 16:59:32 GMT

Thanks for the reply! I have already checked the source, but there was some things I couldn't directly translate to simple BLE communication (like the SoftDevice triggered events) and that's why I'm asking. Will dive further in to the source then.

RE: nrfutil with the builtin BLE interface?

tesc — Tue, 11 Feb 2020 12:11:24 GMT

Hi,

It should be possible, yes, if you change the nrfutil source code from communicating with an nRF dongle over serial to using the native BLE support of the OS. As long as the OS supports BLE 4 there should be no technical restrictions that prevents you from doing something like that. As for the amount of work required it is difficult to say.

The reason for nrfutil not using native OS support for BLE, is mainly that the project was started at a time when such support was virtually non-existing. Still today there are systems out there that lack native support, and we are using the proven and tested transport relying on dongles.

Regards,
Terje