How to perform DFU via PC over BLE?

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? 

Parents
  • 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.

  • 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
    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.
  • 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. */

  • 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.

  • Thanks. Conclusion is then combo of mergehex and nrfutil to program over SWD. I haven't had time yet to investigate if this path works as indicated.

  • Yes,

    You need 4 hex files to begin with:

    1. Softdevice
    2. Bootloader
    3. Application
    4. Bootloader settings page (which you generate with nrfutil)

    All these 4 can be combined into a single hex file using mergehex. Then you have a single hex file that you program via SWD in your production programming, and that is it.

  • Hi Einar,

    I was able to successfully follow the steps in the links you pointed to. Thanks for all your help. One suggestion: it will help other novices like myself, tremendously if it is all contained in a single document, such as the one attached here that I wrote up for my reference. Feel free to share it in the blog. This support ticket can be closed.

    nRF51_programming_tool_chain_guide-v1.0.docx

Reply Children
Related