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.

[Jesper W.]

After doing a DFU today, we have experienced the same, including a mesh assert, caused be the ERROR_CHECK() . see code below

We have not solved the problem our self yet, but to get it up running I guess you have to wait for an flash stable event after the mesh config has been cleared during initialization of the mesh, maybe followed by a system reset (reboot).

void mesh_init(void)
{
    mesh_stack_init_params_t init_params =
    {
        /* Run application and mesh event handling in main loop using app_scheduler:
           When using the APP_SCHED to post event, the irq_priority must be changed from
           NRF_MESH_IRQ_PRIORITY_LOWEST to NRF_MESH_IRQ_PRIORITY_THREAD in order to avoid
           mesh app assert. */
        .core.irq_priority       = NRF_MESH_IRQ_PRIORITY_THREAD, //NRF_MESH_IRQ_PRIORITY_LOWEST,
        .core.lfclksrc           = DEV_BOARD_LF_CLK_CFG,
        .core.p_uuid             = NULL,
        .models.models_init_cb   = models_init_cb,
        .models.config_server_cb = config_server_evt_cb
    };
    ERROR_CHECK(mesh_stack_init(&init_params, &m_device_provisioned));

    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO,"Provisioned:%d\n",m_device_provisioned);

    /* Register event handler to receive LPN, friendship events and NRF_MESH_EVT_FLASH_STABLE.
       Application functionality should be started after receiving NRF_MESH_EVT_FLASH_STABLE event. */
    nrf_mesh_evt_handler_add(&m_mesh_core_event_handler);
}

[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