[NCS v2.6.2] Mounted NVS with BT settings fails to init after a Mcumgr DFU

[ando20]

To explain our problem: We have a system with a NRF52840 chip, we also have an external flash, the settings_subsystem is mounted in the NVS on the internal flash I have included our ninja partition_manager_report below. We are using MCUBoot and Mcumgr to DFU our device. Upon performing a DFU, when the device reboots after the swap, our bt_enable() fails with a settings_subsystem_init() fail with error -45 (-EDEADLK). This error cannot be fixed with a restart, it also cannot be fixed by performing a factory reset on our device which deletes the bluetooth bond keys with a call to bt_unpair(BT_ID_DEFAULT, BT_ADDR_LE_ANY).

There is one way for us to fix the error, we can fix it by erasing the external flash.

We do not understand why erasing the external flash fixes the issue, they seem unrelated.

Flashing it with Jlink does not produce this issue, it only occurs after a DFU.

  external_flash (0x1000000 - 16384kB): 
+------------------------------------------------+
| 0x0: mcuboot_secondary (0xe7000 - 924kB)       |
| 0xe7000: littlefs_storage (0xf19000 - 15460kB) |
| 0x1000000: external_flash (0x0 - 0B)           |
+------------------------------------------------+

  flash_primary (0x100000 - 1024kB): 
+--------------------------------------------------+
| 0x0: mcuboot (0x15000 - 84kB)                    |
+---0x15000: mcuboot_primary (0xe7000 - 924kB)-----+
| 0x15000: mcuboot_pad (0x200 - 512B)              |
+---0x15200: mcuboot_primary_app (0xe6e00 - 923kB)-+
| 0x15200: app (0xe6e00 - 923kB)                   |
+--------------------------------------------------+
| 0xfc000: qual_storage (0x1000 - 4kB)             |
| 0xfd000: user_storage (0x1000 - 4kB)             |
| 0xfe000: settings_storage (0x2000 - 8kB)         |
+--------------------------------------------------+

  sram_primary (0x40000 - 256kB): 
+--------------------------------------------+
| 0x20000000: sram_primary (0x40000 - 256kB) |
+--------------------------------------------+

[Simonr]

Hi

This seems very strange, and a Deadlock from within bt_enable() makes it seem to me that maybe the DFU image is accessing/violating the address ranges used by the Bluetooth controller in your application. 

I was looking for the settings_subsystem_init() function you refer to, but there are no hits in the entire SDK, so I assume you mean the settings_subsys_init() function within bt_settings_init() here?

Can you check which addresses your DFU/Bootloader accesses compared to the original application here, as I assume something is put into the wrong address range or that some address ranges are changed during DFU that causes this issue.

Best regards,

Simon

[ando20]

Hi Simon, 

Thank you for the reply, you are correct in assuming I was referring to `settings_subsys_init()` that was a misstype on my behalf.

For generating and applying the DFU, we are using the exact some code and configuration just incrementing the version number so there should be no difference in addresses. There are minor non-relevant firmware changes to ensure the hashes are different.

We are happy to provide project files that may help your investigation through a private ticket if needed.

Many thanks,
Andrew

[ArchieA_C]

Collueage of ando20, fixed it. Was  due to the partition manger interacting with zephyr,settings-partition