mesh_config_clear() changed behaviour SDK For Mesh 4.2.0

[JonasJ]

With the introduction of mesh_config_file_clear() in 4.2.0 the behaviour of mesh_config_clear() was changed such that only a subset of all the file ids handled by the Mesh Config system is cleared.

This contradicts the behaviour described in the API documentation, "Clean up the file area. It removes all stored file entries."

void mesh_config_clear(void)
{
    m_emergency_action = true;

    FOR_EACH_FILE(p_file)
    {
        if (MESH_OPT_FIRST_FREE_ID > p_file->id)
        {
            mesh_config_file_clear(p_file->id);
        }
    }
}

In the above code the if statement is causing problems as the mesh_config_clear() only considers file ids listed in the MESH_OPT_ enum.

In addition to the above problem, the system requires that all file ids listed in MESH_OPT_ enum is actually used. Especially MESH_OPT_MODEL_FILE_ID is a new file id not used before.

[tesc]

Hi,

I am a bit confused regarding what the first issue is. The documentation for mesh_config_clear() states "clear all configuration data", and that seems to be exactly what it does. For that it uses mesh_config_file_clear(), which deletes the file with the given file ID. Is the issue there that the description of mesh_config_file_clear() could have been better? E.g. clarify that it cleans up only the given file, rather than the current wording: "Clean up the file area. It removes all stored file entries."

Regarding the second issue, yes, it looks like mesh_config_clear() will assert if a file ID is missing. I will report internally.

Regards,
Terje

[tesc]

Hi,

On second thought, regarding the second issue, notice how in mesh_config_clear() only existing files gets iterated. This is not an iteration over the possible file IDs, it is an iteration over the currently stored files. As such, it should be safe.

If you see a different issue, or I have misunderstood something, then please direct me to it and I will have a look.

Regards,
Terje

[JonasJ]

Hi tesc,

It is not iterating over existing file ids, only those specified in an enum which doesn't mean that the file id is actually registered in the Mesh Config file table (MESH_CONFIG_FILE()).

I've removed registration of MESH_OPT_MODEL_FILE_ID as it was forced on the user for no good reason. See my other report on this issue, https://devzone.nordicsemi.com/f/nordic-q-a/66792/use-of-additional-flash-page-in-sdk-for-mesh-4-1-0-for-light-lc-ctl-lightness-models

The other issue is that the mesh_config_clear() changed behaviour when it comes to cleaning up other files registered by the user using MESH_CONFIG_FILE() macro. Previous version would delete all entries registered regardless of the file id, the current version limits the cleaning to entries in the file ids listed in the enum.

I my mind the limiting condition in mesh_config_clear() should be removed. Why is the condition there to begin with?

Thanks.

[tesc]

Hi,

Right. Sorry. Without delving too deep in the macros I thought the FOR_EACH_FILE macro did something slightly different from what it does. Yes, looks like it iterates over a section containing mesh_config_file_params_t structures, expecting that section to hold more instances than previously (due to the added MESH_OPT_MODEL_FILE_ID file ID), and a bug of the nature that you describe seems likely.

I have reported internally, for the mesh team to look into. I expect to have answers next week.

Regards,
Terje

[tesc]

Hi,

The change of behaviour in mesh_config_clear() was intentional. Files written by the user of the library should also be cleaned up by the user of the library. Sometimes there can be valid reasons to hold user data files intact even after node reset, and so to implement a full "factory reset" you need to explicitly delete those files as well.

Regarding the issue of iterating over the enum of config files and asserting, I am told this has been fixed (and will be part of next SDK release). I have asked what the fix is so that I can share it.

Regards,
Terje