assert flash Memory Metadata not aligned after FOTA

[Simsim]

Hi There

I run a NRF52840 with the MESH SDK, and use the Flash manager provided.

After some time i would like to update the Device over FOTA this ends in a Assert on booting with the new firmware at the point flash_manager.c Line 256

NRF_MESH_ASSERT(p_manager->config.p_area[i].metadata.pages_in_area == p_manager->config.page_count);

when erase the full mcu this assert is not showing up due no existing data.

In the best case i can keep the data in the Fields, when not how to erase the Flash bevore or at the FOTA?

Regards Simon

[Hieu]

Hi Simon,

Then it makes sense now. The application is hitchhiking the Mesh stack's configuration system to store its data.

Therefore, even though you do not change any Mesh configurations, when you change your application data size, it changes the Mesh configuration data size, causing the assert.

I was not aware of this approach to store application data. Apparently, that is documented. 

I will now propose a few directions:

1. Switch to using an independent Flash Manager instance to store application data.

You now create a new flash_manager_t with enough space to store all of the data in the new firmware.

Remember to do so after Mesh stack initialization and use mesh_config_backend_flash_usage_get() to make sure the application's Flash Manager is independent of the Mesh stack.

You also keep the previous hitchhiking implementation as is, no change to size.

On first boot of the new firmware, after Mesh stack initialization (which shouldn't assert anymore) and the flash_manager_add() call of the new manager, the firmware check for data in the new application Flash Manager. If the data isn't there, it then performs (or schedule) a migration of the data from the old system to the new one.

Then after that, it goes on to work normally.

This also means that you don't have to sacrifice the Mesh data with mesh_stack_config_clear(). The device won't need to be reprovisioned.

Another factor to consider here is future proofing to prevent further change to data layout.

If you think that Mesh configurations might be changed in the future, then you will want to initialize the application's Flash Manager instance one or two pages away from the Mesh stack's data.

If you also expect that the application data will change in another update, it is also a good idea to reserve some extra space for it.

It will also be important to document the known flash memory layout carefully for future maintainers.

2. Keep old application data with the Mesh Configuration solution. Create a new Flash Manager instance to store only the new data.

The caveats regarding placement of the new Flash Manager instance in option 1 also applies here.

3. Stay with the Mesh Configuration Module storage solution.

If you prefer to stay with the Mesh Configuration hitchhiking approach, then you need to figure out how to trigger mesh_stack_config_clear() on the new application exactly once on the very first boot of the new firmware version, before the assert.

However, I am unable to figure out what signs/basis the application can use to call mesh_stack_config_clear()... Is there something particular to your project that can help here?

I have a feeling that will be hacky/workaround-ish. If you also find it so, I recommend the other two options more.