Bonding randomly loss after DFU

Hi there,

I am using nrf connect sdk v2.6.0. I have noticed that after DFU update, I am seeing ble bonding lost randomly on firmware side. I did uncheck Erase Application Settings before DFU and I tried on both Device Manager app as well as nrf connect app and on both Android/IOS. I am attaching dts snippet and prj.conf for reference.

Thanks M

&flash0 {

	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 0x0000C000>;
		};
		slot0_partition: partition@c000 {
			label = "image-0";
			reg = <0x0000C000 0x00076000>;
		};
		slot1_partition: partition@82000 {
			label = "image-1";
			reg = <0x00082000 0x00076000>;
		};

		/*
		 * The flash starting at 0x000f8000 and ending at
		 * 0x000fffff is reserved for use by the application.
		 */

		/*
		 * Storage partition will be used by FCB/LittleFS/NVS
		 * if enabled.
		 */

		app_storage_partition: partition@f8000 {
			label = "appstorage";
			reg = <0x000f8000 0x00006000>;
		};
		storage_partition: partition@fe000 {
			label = "storage";
			reg = <0x000fe000 0x00002000>;
		};
	};
};

6786.prj.conf

Parents Reply Children
  • Hi Amanda,

    Yes I did and I did uncheck "Erase application settings" everytime in the app before DFU.

    Regards,
    M

  • Could you remove the partition in dts and let the partition manager automatically generate it to see it can help or not?

  • Hi , If I remove from dts, It doesn't get build. FYI I do have static partition defined too. 

    app:
      address: 0xc200
      end_address: 0xfe000
      region: flash_primary
      size: 0xf1e00
    external_flash:
      address: 0xf2000
      end_address: 0x400000
      region: external_flash
      size: 0x30e000
    mcuboot:
      address: 0x0
      end_address: 0xc000
      placement:
        before:
          - mcuboot_primary
      region: flash_primary
      size: 0xc000
    mcuboot_pad:
      address: 0xc000
      end_address: 0xc200
      placement:
        align:
          start: 0x1000
        before:
          - mcuboot_primary_app
      region: flash_primary
      size: 0x200
    mcuboot_primary:
      address: 0xc000
      end_address: 0xfe000
      orig_span: &id001
        - app
        - mcuboot_pad
      region: flash_primary
      size: 0xf2000
      span: *id001
    mcuboot_primary_app:
      address: 0xc200
      end_address: 0xfe000
      orig_span: &id002
        - app
      region: flash_primary
      size: 0xf1e00
      span: *id002
    mcuboot_secondary:
      address: 0x0
      device: DT_CHOSEN(nordic_pm_ext_flash)
      end_address: 0xf2000
      placement:
        align:
          start: 0x4
      region: external_flash
      share_size:
        - mcuboot_primary
      size: 0xf2000
    app_storage_partition:
      address: 0xf8000
      end_address: 0xfc000
      region: flash_primary
      size: 0x6000
    settings_storage:
      address: 0xfe000
      end_address: 0x100000
      placement:
        align:
          start: 0x1000
        before:
          - end
      region: flash_primary
      size: 0x2000
    sram_primary:
      address: 0x20000000
      end_address: 0x20040000
      region: sram_primary
      size: 0x40000
    

  • Hello

    I am facing the same issue. I feel like it is related to the application size even if the settings partition is exactly the same in both partitions manager.

    I explain myself : I programmed 2 different versions (47 and 50) of my BLE peripheral application in 2 application slots of 1 product. Both versions have differences, not related to advertising or pairing, but they ended up not having the same size. I connect my product in v50 to my phone with bounding etc, everything is fine I can reset either my phone or my product and they re connect automaticaly.  When I swap my product in v47 with nRF Connect application for smartphone I can't connect to my phone anymore, I have disconencted reason 19 in the log of my product meaning bouding informations have been lost. But if i swap back my product to v50 I can connect again. 

    Here is screenshots illustrating my words : 

    Screenshot from the programmer of nRF Connect for Desktop, showing both application are of different sizes.

      

    v47 partitions manager

    v50 partitions manager

    My applications are based on sdk v2.5.0.

    May the issue come from the settings_load() function ? Maybe instead of looking to a particular address it is using the difference between the end of the application and the beginning of settings storage partition ?

  • Great. You seeing same issue. If we have defined settings at a fixed address, do you think it should always look at the exact address everytime regardless of slot 0 or slot 1 application?

Related