DSM/Access Metadata clear after change doesn't work properly in Mesh SDK 4.0.0

[JonasJ]

In case the DSM metadata is changed compared to what is stored on flash, the 4.0.0 code is supposed to clear the flash from any configuration but this doesn't work properly for metadata.

When mesh_config_load() reads all entries from flash, dsm_metadata_setter() is called and detects that the metadata has changed and returns NRF_ERROR_INVALID_DATA.

Returning NRF_ERROR_INVALID_DATA will trigger a LOAD_FAILURE_INVALID_DATA and the MESH_CONFIG_ENTRY_FLAG_ACTIVE flag is never set for this entry.

Later on when dsm_mesh_config_clear() is called due to the previous LOAD_FAILURE_INVALID_DATA the call to mesh_config_entry_delete() will do nothing as the MESH_CONFIG_ENTRY_FLAG_ACTIVE was never set.

As the correct metadata is never written after dsm_clear the old broken metadata will remain for ever in flash causing the persistent storage to fail on every boot.

The same problem applies to access layer as well.

By looking at the code, the mesh_config API could use a mesh_config_clear_file() which would actually erase the backend page properly instead of manually erasing each and every entry.

Thanks.

[tesc]

Hi,

Thank you for the detailed descripiton. It is highly appreciated! Our mesh team has looked into the issue, and we intend to fix this for next nRF5 SDK for Mesh release. Unfortunately we do not have a fix as of yet, but we are looking into how to best solve this without creating new issues in the process. Implementing a mesh_config_file_clear() looks like a promising fix and an improvement over the current API.

Regards,
Terje

[Jesper W.]

Think it is handled in latest Mesh release .. look at the light_switch/client  example.

At least this example accept return code from  mesh_stack_init() different from NRF_SUCCESS.

[tesc]

Hi,

I see that it is unclear what "this" refers to in my previous post. I was commenting on the DSM metadata issue mentioned by JonasJ in the opening post, not to the assert on ERROR_CHECK(). I am sorry for the confusion!

Please note that non-NRF_SUCCESS return value from mesh_stack_init() indicates something is wrong, and so should be handled appropriately. What return value did you experience?

Regards,
Terje