How to perform DFU via PC over BLE?

[kishanjsing]

Any instructions or link I can follow to do this instead of having to use an iOS or Android  mobile device with the nRF Connect mobile app? 

[Einar Thorsrud]

Hi,

Are you using the nRF5 SDK or the nRF connect SDK? In either case, we do not provide any libraries intended to perform DFU from a PC to integrate in your (potential) custom application, but we do provide some tools intended for development and testing.

If using the nRF5 SDK, you can perform DFU from a computer using nRF Connect Bluetooth LE. You can also use nrfutil for a command line tool. Note that you will need to have a DK or dongle connected to the PC (this does not use any native BLE support or device in the computer).

If using the nRF Connect SDK, you can use mcumgr.

[kishanjsing]

Hi Einar,

I am using nRF5 SDK. I tried nRF Connect BLE to no avail. I connect my J-Link EDU device to the SWD i/f of my nRF52832 custom board and click on SELECT DEVICE in nRF Connect for Desktop Bluetooth Low Energy Standalone v4.0.4. The app shows J-Link + S/N. When I click on it, I get the following output in the log:

15:59:12.647

Using nrf-device-lib-js version: 0.4.4

15:59:12.648

Using nrf-device-lib version: 0.10.3

15:59:12.648

Using nrfjprog DLL version: 10.15.1

15:59:12.648

Using JLink version: JLink_V7.80c

15:59:12.683

Installed JLink version does not match the provided version (V7.66a)

15:59:12.840

Updated list of uuids with data from https://github.com/NordicSemiconductor/bluetooth-numbers-database/tree/master/v1

15:59:19.590

Selected device with s/n 000260117415

15:59:19.601

Error while setting up device 000260117415: Error: No serial port available for device with serial number 000260117415

15:59:19.603

Device closed.

I tried it with an nRF5-DK board and aside from not seeing it advertised, the app does properly establish the connection with the board.

For your reference, DFU OTA works fine using the nRF Connect iOS mobile app with the custom board. But I don't want to use that approach because I need to enable the manufacturer of the custom board, and using a laptop or desktop PC is preferred. 

I tried using mergehex followed by nrfutil, but that only works for merging the secure bootloader and the softdevice. When merging the bootloader, softdevice and the application hex files with mergehex, using nrfutil fails to program the custom board properly.

[Einar Thorsrud]

Hi,

You cannot use a normal Segger debugger with nRF Connect Bluetooth. It relies on the nRF chip on a DK or a dongle for Bluetooth conectivity. So you need to use a DK. To be clear, this DK connected to the PC and that you use with nRF Connect, is then used as part of the DFU master side. And can communicate over BLE with the device you want to upgrade. Once you get that working (can scan BLE devices etc), you are ready to try to do DFU of the device.

To do DFU via nRF Connect, you will need to provide a zip image just as you do with nRF Connect for iOS, so I suggest you use an image you know is working (that you had working with nRF Connect for iOS).

[kishanjsing]

Hi Einar,

I may not have been clear in explaining, my apologies for that. So let me try again.

The custom board has SWD support. I can use the iOS or Android nRF Connect mobile app to do DFU over BLE. But that is not desirable for the manufacturer. They require a PC based solution.

The only way I can connect the board to a PC is via a J-Link device, connecting to the board via the SWD i/f and to the PC via USB. The manufacturer can use nRFutil to flash the merged bootloader + softdevice hex file to the board in this setup. But the has to flash the application via nRF Connect for iOS or Android, because using nRFutil to flash a merged bootloader + softdevice + application hex file doesn't work. What am I doing wrong?

[Einar Thorsrud]

Hi,

OK, so in production programming you first flash the bootloader + SoftDevice hex via SWD, then you use DFU via BLE to program the application. Is that correct? May I ask why don ton't also flash the application + bootloader settings page, so that you do all the programming in one go?

Though it seems odd, if you really want to DFU in the application via DFU over BLE from a PC, you need to do as I attempted to describe in my previous post (after first have programmed the bootloader + SoftDevice via SWD). That is to use either nRF Connect Bluetooth Low Energy as described in the documentation DFU over Bluetooth Low Energy, or use nrfutil as described under Updating firmware over the air. Note that in both cases you will need an nRF DK or dongle. 

[kishanjsing]

Yes, that's correct. I followed the instructions in the link provided for the bootloader settings page, but can't seem to find the bootloader version in the nrf_dfu_type.h file. See below. A search in the bootloader project itself also turned up nothing.

As for using an nRF DK or dongle, that's not an option as the custom board has only a SWD i/f.

 C:\nRF5_SDK_15.3.0_59ac345\components\libraries\bootloader\dfu\nrf_dfu_types.h (9 hits)
Line 70: #define INIT_COMMAND_MAX_SIZE_v1 256 /**< Maximum size of the init command in settings version 1. */
Line 230: #define NRF_DFU_PEER_DATA_LEN 64 /**< The length in bytes of nrf_dfu_peer_data_t expected by tools manipulating the settings page. Do not change without changing the settings page version. */
Line 231: #define NRF_DFU_ADV_NAME_LEN 28 /**< The length in bytes of nrf_dfu_adv_name_t expected by tools manipulating the settings page. Do not change without changing the settings page version. */
Line 306: uint32_t settings_version; /**< Version of the current DFU settings struct layout. */
Line 306: uint32_t settings_version; /**< Version of the current DFU settings struct layout. */
Line 307: uint32_t app_version; /**< Version of the last stored application. */
Line 307: uint32_t app_version; /**< Version of the last stored application. */
Line 308: uint32_t bootloader_version; /**< Version of the last stored bootloader. */
Line 308: uint32_t bootloader_version; /**< Version of the last stored bootloader. */

[Einar Thorsrud]

kishanjsing said:

Yes, that's correct. I followed the instructions in the link provided for the bootloader settings page, but can't seem to find the bootloader version in the nrf_dfu_type.h file. See below. A search in the bootloader project itself also turned up nothing.

The bootloader version is a number you pick, versioning your bootloader, and you provide it when you make the bootloader settings page and when you make a DFU oackage (if that contains a new bootloader). So you could start with 1, then 2 if you update it, etc. (That is used primarily for down-grade prevention.)

kishanjsing said:

As for using an nRF DK or dongle, that's not an option as the custom board has only a SWD i/f.

Then DFU from a desktop computer is not an option unless you make the DFU master software yourself. I anyway does not seem to make much sense here, as doing production programming over SWD (and programming the whole firmware, not just the bootloader and SoftDevice) makes a lot more sense in production programming in general, where time and reliability is typically essential.