This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Buttonless DFU with bond not working

Hi,

I'm struggling to get Buttonless DFU with bond enabled working.

Setup details:

1) SDK 14.2

2) DK board - nrf52832

3) nrfconnect app on Android phone (8.0) :

DFU settings = Pkts receipt notification procedure : ON

Number of packets : 10

MBR : 4096

Keep bond information: ON

External MCU DFU : OFF

4) Custom app with bond enabled, BLE_GAP_ADDR_TYPE_RANDOM_STATIC(C1:C1:C1:C1:C1:C1), MITM enabled,

Followed the steps to generate bootloader keys and everything seems to be fine. Flashed SD, BL, APP onto DK board and I can see the app running.

Connected nrfconnect to my custom app, paired succesfully. I can see secure DFU service with Secure buttonless DFU.

After enabling the indication, I write value "0x01" and send to switch to DFU mode. I see device moved to DFU mode but with BD addr = EA:F8:73:D2:B8:CC.

Connected nrfconnect to DfuTarg and if I try to DFU, I think device switches to my custom app and I don't see DFU happening any more.

I'm wondering what would be wrong and I believe encryption fails due to different BD address used in DFU and app mode. What am I missing?

Tried looking into Nordic blogs, dev support but could not move forward. Also, I tried to see the DFU NRF log but I don't see any log messages

All I see on power ON is

<info> µ˜°: Setting vector table to bootloader: 0x00066000
<info> µ˜°: Setting vector table to main app: 0x00023000
<info> µ˜°: Record ID:    0x0001
<info> µ˜°: File ID:    0xF020
<info> µ˜°: Record key:    0x7010

I did used \nRF5_SDK_14.2.0_17b948a\examples\dfu\bootloader_secure_ble\pca10040_debug\armgcc\Makefile with logger enabled and optimization is -O0 in makefile. I'm not sure DFU logger does not show up in RTT viewer.

Attached are the config,make files for reference.

Your help is highly appreciated.

dfu.rarapp.rar

  • Hello,

    Sorry. I was out of office the previous week. I see that you have been working a bit on this. I assume from your last reply that it is working now. Is that correct?

     

    Best regards,

    Edvin

  • Hi Edvin,

    The GATT_WRITE issue is resloved but I still see the INVALID_OBJECT. please see the above digest for more details.

    Regards

    Suresh

  • Hello,

    I understand.

    Yes. 0x9D is the correct sd-req. You can see the list of the different softdevices by typing the command:

    "nrfutil pkg generate --help".

     

    In the project that I sent you I used your project, and the bootloader found in SDK14.2.0\examples\dfu\bootloader_secure_ble\pca10040\arm5_no_packse.

    The only changes are:

    in sdk_config.h: #define NRF_DFU_BLE_REQUIRES_BONDS 1

    and the gap_params_init() function, as described above, to change the address when the bootloader starts.

    INVALID_OBJECT means that the DFU packet that you are sending is not accepted by the bootloader. The reasons for this is usually that it has used a wrong signing key (private.key), wrong hw-version, wrong sd-req or insufficient application-version.

     

    It seems like the hw-version, sd-req is correct. I assume that you use the same private.key as you use without bonding, so I assume that it is correct as well.

    This leaves the application-version.

     

    Do you use the same keyset with your bootloader with and without bonding? If not, are you sure you are not mixing them up?

     

    The difference when you require bonding and when you don't require bonding is that you need to store some bootloader settings that accepts the first application, which is required for bonding with the device that is going to perform the DFU transfer. This is not needed in DFU without bonding, because you can start directly in bootloader mode, without having any bonding information stored.

     

    I tested your files (my_bin.rar) with my bootloader(changed the private.key to the one you included). Then flashed the sd_bl_app_merged.hex file, and the bootloader_settings.hex-file (I also tried without. Didn't know whether it was merged in the other file).

    I also get the INVALID_OBJECT message. What application-version do you use in your bootloader_settings file? Have you changed anything else in the bootloader, other than what we have discussed? 

     

    BR,

    Edvin


  • >> In the project that I sent you I used your project, and the bootloader found in SDK14.2.0\examples\dfu\bootloader_secure_ble\pca10040\arm5_no_packse.
    Could you try with "nRF5_SDK_14.2.0_17b948a\examples\dfu\bootloader_secure_ble\pca10040_debug\armgcc" with sdk_dfu_config.h file attached in my_dfu.zip please.

    >> It seems like the hw-version, sd-req is correct. I assume that you use the same private.key as you use without bonding, so I assume that it is correct as well.
    I generated the private.key, public_key.c, building micro-ecc library file afresh using below commands(all these runs in batch file)

       nrfutil.exe keys generate private.key
       nrfutil keys display --key pk --format code private.key --out_file public_key.c

       cd C:\Data\Project\Device\SDK\nordic\nRF5_SDK_14.2.0_17b948a\external\micro-ecc\nrf52hf_armgcc\armgcc
       rm -r _build
       make
       
       copy C:\Data\Project\Device\repository\device\nordic\tools\public_key.c C:\Data\Project\Device\SDK\nordic\nRF5_SDK_14.2.0_17b948a\examples\dfu\dfu_req_handling\public_key.c

       cd C:\Data\Project\Device\SDK\nordic\nRF5_SDK_14.2.0_17b948a\examples\dfu\bootloader_secure_ble\pca10040_debug\armgcc
       rm -r _build
       make

    >> Do you use the same keyset with your bootloader with and without bonding? If not, are you sure you are not mixing them up?
    I usually clean up the old keys to not confuse with stray files. So, it is always fresh set key-pairs.
     
    >> The difference when you require bonding and when you don't require bonding is that you need to store some bootloader settings that accepts the first application,
    What bootloader settings I might have missed?

    >> I also get the INVALID_OBJECT message. What application-version do you use in your bootloader_settings file?  
    When sd_bl_app_merged.hex is generated application-version = 1 and when generating dfu package it is 2. You can verify with nrfutil display command for confirmation.

    The way sd_bl_app_merged.hex file generated is as below (you can also generate using my app makefile command flash_sd_bl_app)

    nrfutil settings generate --family NRF52 --application C:\Data\Project\Device\repository\device\nordic\gcc\power_strip\_build\nrf52832_xxaa.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 C:\Data\Project\Device\repository\device\nordic\gcc\power_strip\_build\bootloader_setting.hex
    Generated Bootloader DFU settings .hex file and stored it in: C:\Data\Project\Device\repository\device\nordic\gcc\power_strip\_build\bootloader_setting.hex

    Bootloader DFU Settings:
    * File:                 C:\Data\Project\Device\repository\device\nordic\gcc\power_strip\_build\bootloader_setting.hex
    * Family:               nRF52
    * Start Address:        0x0007F000
    * CRC:                  0x539861AA
    * Settings Version:     0x00000001 (1)
    * App Version:          0x00000001 (1)
    * Bootloader Version:   0x00000001 (1)
    * Bank Layout:          0x00000000
    * Current Bank:         0x00000000
    * Application Size:     0x00012D44 (77124 bytes)
    * Application CRC:      0xEEC9D449
    * Bank0 Bank Code:      0x00000001

    mergehex --merge C:\Data\Project\Device\repository\device\nordic\gcc\power_strip\_build\bootloader_setting.hex C:\Data\Project\Device\SDK\nordic\nRF5_SDK_14.2.0_17b948a\examples\dfu\bootloader_secure_ble\pca10040_debug\armgcc\_build\nrf52832_xxaa_s132.hex  --output C:\Data\Project\Device\repository\device\nordic\gcc\power_strip\_build\bootloader_merged.hex
    Parsing input hex files.
    Merging files.
    Storing merged file.
    mergehex --merge C:\Data\Project\Device\SDK\nordic\nRF5_SDK_14.2.0_17b948a\components\softdevice\s132\hex\s132_nrf52_5.0.0_softdevice.hex C:\Data\Project\Device\repository\device\nordic\gcc\power_strip\_build\bootloader_merged.hex C:\Data\Project\Device\repository\device\nordic\gcc\power_strip\_build\nrf52832_xxaa.hex --output C:\Data\Project\Device\repository\device\nordic\gcc\power_strip\_build\sd_bl_app_merged.hex
    Parsing input hex files.
    Merging files.
    Storing merged file.

    DFU package is generated as below

    nrfutil pkg generate --hw-version 52 --sd-req 0x9d --application-version 1 --application C:\Data\Project\Device\repository\device\nordic\gcc\power_strip\_build\nrf52832_xxaa.hex  --key-file C:\Data\Project\Device\repository\device\nordic\gcc\power_strip\_build\private.key C:\Data\Project\Device\repository\device\nordic\gcc\power_strip\_build\app_dfu_package.zip
    Zip created at C:\Data\Project\Device\repository\device\nordic\gcc\power_strip\_build\app_dfu_package.zip

    I suggest you try with gcc version and please use my app makefile commands to generate sd_bl_app_merged.hex and app_dfu_package.zip so that we are in sync(ignore this line if you are already doing it)

    >> Have you changed anything else in the bootloader, other than what we have discussed?
    I have attached all the files which I changed in bootloader but I believe those should not cause this issue.

    Regards
    Suresh
    my_dfu.zip

  • Hello,

    Attached you will find a fresh copy of the SDK, where I only replaced the files you attached in my_dfu.rar and power_strip.rar.

    Your app is located in SDK\examples\Suresh\power_strip\power_strip

    the bootloader is located in SDK\examples\dfu\bootloader_secure_ble\pca10040\armgcc

     

    There (in the bootloader folder) you will also find a folder called "application". When you run SDK\examples\dfu\bootloader_secure_ble\pca10040\arngcc\flash_everything.bat it will run your prog_uicr.bat code, flash softdevice, bootloader, bootloader_settings, and application, then reset, and then create the dfu_packages inside the "application" folder. Try to connect to it with nRF Connect and then bond, and upload one of the dfu packs, Suresh_app2.zip or Suresh_app3.zip. They have application version 2 and 3, respectively (the application already running has application version 1, so the packets must start at 2).

     

    The only file I didn't replace in the SDK was the makefile.windows, because I had to use my own compiler. Just edit that file, and you should be able to compile your own version of the bootloader, with a new set of keys(as well of your own application). The keys, by the way, are also located in the bootloader folder (armgcc).

     

    Give it a go, and let me know if this one works for you.

     

    SDK14.2.0_Suresh.zip

     

    Best regards,

    Edvin

Related