Assert after DFU, flash_manager issue : NRF_MESH_ASSERT(p_manager->config.p_area[i].metadata.page_index == i);

Hi,

We are facing the same issue as in this post but the solution is not working for us. The old post :  https://devzone.nordicsemi.com/f/nordic-q-a/109161/problem-with-flash_manager-nrf_mesh_assert-p_manager--config-p_area-i-metadata-page_index-i 

After DFU we have the same assert when the system is booting. So the assert is here : NRF_MESH_ASSERT(p_manager->config.p_area[i].metadata.page_index == i);

What I understand is that the DFU overwrite some of our application data and that trigger the assert. How can we handle this ?

Our application size is 464ko (.hex size) with the opitimisation for size activated.
maybe it is not the way to know the real size of the app ?

Is it too big to use the DFU ? if yes, What is the limit when using DFU ?
Is it really a size issue or rather a problem with the place where or custom data in flash are stored ?

We use the "mesh_config" (MESH_CONFIG_ENTRY) system to write and read in flash. Like it is done in nordic example for every models. We added one for a generic user property model.
We use these id's (in the model_config_file.h) : 
#define MESH_APP_MODEL_GENERIC_USERPROPERTY_ID_START (0x2700)
#define MESH_APP_MODEL_GENERIC_USERPROPERTY_ID_END (0x27FF)

We already tried to remove this part we added but the assert still appear so we are not convinced it is related to this.

Waiting your answer ! thx :)

Here are the logs : 

Here is the start when it success : 

<t:          0>, main.c, 3652, ----- BLE Mesh LPN Demo -----
<t:      11749>, main.c, 3667, ----- 4 -----
<t:      12256>, flash_manager_defrag.c,  630, BOOTLOADERADDR(): 0x00072000 fm_recovery_area: 0x00070000
<t:      12264>, mesh_config_flashman_glue.c,  351, Mesh config area: 0x0006F000 file_id: 0x0000
<t:      12268>, flash_manager.c,  822, FM area: 0x0006F000
<t:      12276>, mesh_config_flashman_glue.c,  351, Mesh config area: 0x0006E000 file_id: 0x0001
<t:      12280>, flash_manager.c,  822, FM area: 0x0006E000
<t:      12288>, mesh_config_flashman_glue.c,  351, Mesh config area: 0x0006D000 file_id: 0x0002
<t:      12292>, flash_manager.c,  822, FM area: 0x0006D000
<t:      12300>, mesh_config_flashman_glue.c,  351, Mesh config area: 0x0006C000 file_id: 0x0003
<t:      12303>, flash_manager.c,  822, FM area: 0x0006C000
<t:      12311>, mesh_config_flashman_glue.c,  351, Mesh config area: 0x0006B000 file_id: 0x0004
<t:      12315>, flash_manager.c,  822, FM area: 0x0006B000
<t:      12323>, mesh_config_flashman_glue.c,  351, Mesh config area: 0x0006A000 file_id: 0x0005
<t:      12327>, flash_manager.c,  822, FM area: 0x0006A000
<t:      12335>, mesh_config_flashman_glue.c,  351, Mesh config area: 0x00069000 file_id: 0xFFFE
<t:      12339>, flash_manager.c,  822, FM area: 0x00069000
advertiser_interval_set : 1000
<t:      12356>, userproperty_model_client.c,   63, INIT BUFFER DONE
<t:      12359>, userproperty_model_client.c,   63, INIT BUFFER DONE
<t:      12385>, main.c, 3509, advertiser_instance_init OK
<t:      12387>, main.c, 3669, ----- 5 -----

And there is the start after DFU with the assert : 

lfclk_config ok
rtc_config ok
<t:          0>, main.c, 3651, ----- BLE Mesh LPN Demo -----
<t:      11650>, main.c, 3666, ----- 4 -----
<t:      12160>, flash_manager_defrag.c,  630, BOOTLOADERADDR(): 0x00072000 fm_recovery_area: 0x00070000
<t:      12167>, mesh_config_flashman_glue.c,  351, Mesh config area: 0x0006F000 file_id: 0x0000
<t:      12171>, flash_manager.c,  822, FM area: 0x0006F000
<t:      12174>, mesh_config_flashman_glue.c,  351, Mesh config area: 0x0006E000 file_id: 0x0001
<t:      12178>, flash_manager.c,  822, FM area: 0x0006E000
<t:      12182>, mesh_config_flashman_glue.c,  351, Mesh config area: 0x0006D000 file_id: 0x0002
<t:      12185>, flash_manager.c,  822, FM area: 0x0006D000
<t:      12189>, mesh_config_flashman_glue.c,  351, Mesh config area: 0x0006C000 file_id: 0x0003
<t:      12193>, flash_manager.c,  822, FM area: 0x0006C000
<t:      12195>, app_error_weak.c,  105, Mesh assert at 0x0002F3A6 (:0)

Parents Reply Children
  • Hello,

    We didn't really find a solution. What we do now is that we test the size of the application to be sure that when the DFU it does not write data in the mesh_config pages.

    So if application is small, it does the dual bank without reaching the "problematic areas".
    If the application is big, it does a single bank and so don't write in the problematic areas.
    If it is between, we have the assert occuring.
    So the issue happens just with a range of specific sizes. We pay attention to not be in this size.
    It will be an issue for later if we do not correct this !!!

    If you can help us resolving the issue, it would be great !
    Our method is only to have it to work, it is not intended to stay like this ...

    Thank you!
    Waiting for your answer.

  • Hi,

    If I understand this correctly, the problem is that in some cases when dual bank is used, you see that the new application is temporarily stored in the area used by the Flash manager library from the nRF5 SDK for Mesh.

    The nRF5 SDK Secure Bootoader has no knowledge of the BLE mesh specific libraries, and assumes it can use any space between the SoftDevice end and FDS or other Application data (see Memory layout). In other words what you are doing is not supported out of the box, and special considerations are needed.

    There are potentially several ways to handel this. I am not very familiar with the SDK for Mesh, but it is possible to specify the location of the flash manager pages using FLASH_MANAGER_RECOVERY_PAGE as described in the documentation. If you place this right nex to the bootloader, and reserve that region in the bootloader by setting NRF_DFU_APP_DATA_AREA_SIZE in the bootloader's sdk_config.h accordingly, the bootloader will know that this cannot be touched, and it will use singel bank automatically if dual banking would involve writing to this region. This seems to me to be the cleanest way to handle this.

Related