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

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

ArchieA_C — Thu, 20 Feb 2025 17:03:55 GMT

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

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

ando20 — Thu, 20 Feb 2025 13:58:13 GMT

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

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

Simonr — Thu, 20 Feb 2025 13:43:27 GMT

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