MESH Coexistence mesh_config_backend_init

[CanuckAbroad]

I am incorporating the MESH 5.0.0 coexistence example over an existing BLE application. I have run into an issue that I have been unable to resolve involving Persistent Storage in the MESH code.

The error is detected within the function void mesh_config_backend_init(...). The NRF_MESH_ASSERT calls fail. These asserts are called within a for loop just after mesh_config_backend_glue_init(...) is called and returned from.

We do use FDS and Fstorage in other areas of our code and I am thinking that there is a space or timing conflict but I am unable to determine or validate this. 

Any help is greatly apprciated.

Thank you

[tesc]

Hi,

First, make sure you do everything as described in the guide for including nRF5 SDK for Mesh functionality in an nRF5 SDK example. In particular, for flash storage there are a couple of important bullet points (the last two bullet points) under Optional changes. I.e. you must add the required contents to nrf_mesh_config_app.h and after adding nrf_mesh_config_app.h with required modifications.

If you still see errors, plase share the exact line of code and any other information related to the assert or error that you see.

Regards,
Terje

[CanuckAbroad]

Hi, 

Thank you for the response.

I have followed the guide quite closely for porting MESH into an existing BLE application. The noted points (the last two bullet points) were completed as described.

The error chain starts when we call the function chain starting with:

mesh_init(...) > mesh_stack_init(...) > nrf_mesh_init(...) > mesh_config_init(...) > mesh_config_backend_init(...) 

within that function there is the following code:

(about line 104 of mesh_config_backend.c)

for (uint32_t itr = 0; itr < entry_count; itr++)
{
const mesh_config_file_params_t * p_file = file_get(p_entries[itr].p_id->file);
NRF_MESH_ASSERT(p_file != NULL && p_file->p_backend_data != NULL);
uint32_t size_guard = p_file->p_backend_data->size +
mesh_config_record_size_calculate(p_entries[itr].entry_size) * p_entries[itr].max_count;
NRF_MESH_ASSERT(size_guard <= UINT16_MAX);
p_file->p_backend_data->size = size_guard;
p_file->p_backend_data->entry_count += p_entries[itr].max_count;
}

The assert fails usually on the 3rd or 4th iteration of the loop. In digging a bit deeper the header information seems to be invalid.

This error occurs on a system that has run only once on a memory erased board, first run through. we do use fstorage for persistence storage in the older BLE application. The older BLE code is initialized first.

mesh_init() and then mesh_start() are the last two calls prior to entering the idle state handle for loop at the end of main(...), so all other functionality is up and running when we initialize and then start mesh support.

Thank you

[tesc]

Hi,

First of all I am very sorry for the delayed response.

I could have a look at the flash contents in this state, in order to determine if this looks like a conflict between FDS and the mesh Flash manager.

For that I would need a flahs dump including the UICR registers. If you don't want to share that in a public ticket, you can create a private ticket, attach the flash dump there, and refer back to this thread from that ticket.

I prefer the .hex file format for the dump, which you can get from the command:

nrfjprog --readcode --readuicr dump.hex

In any case you can double check that FLASH_MANAGER_RECOVERY_PAGE is not set; because if it is then the FLASH_MANAGER_RECOVERY_PAGE_OFFSET_PAGES will not apply. If FLASH_MANAGER_RECOVERY_PAGE overlaps with FDS flash then that may lead to error.

Regards,
Terje