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

[ValentinL]

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)

[tesc]

Hi,

There seems to be some issues with my latest answer in the other thread. I have tried to repost it there:  RE: Problem with flash_manager, NRF_MESH_ASSERT(p_manager->config.p_area[i].metadata.page_index

Please let me know if there are any further issues.

Regards,
Terje

[ValentinL]

Hello,

I work several days on the Issue but I still don't have a fully working DFU.
But I tried many things and understand better so I can precise my issue.
I hope you could help because I have no more ideas.

1) I am working with nrf sdk for mesh ! My modules are mesh modules. But we want to do the DFU not over mesh but with an App, like the DFU nordic App for exemple. We program the bootloader of basic sdk (not mesh).
It works not fully so maybe it is related to the "mesh" stack. -> my assert is with "mesh configuration" so I think maybe it is an uncompatibility issue with memory placement,...

I use an nrf52833.

2) For the bootloader, I use the project : secure_bootloader_ble_s140_nrf52833_debug from bootloader_dfu_nrf_16.0.0.

3) The DFU works correctly in DUAL BANK when my application is not too big. With a certain size, I have my assert.
I explain : My mesh_configuration writes in Pages of the flash memory at 6F000, 6E000, 6D000, 6C000, 6B000, 6A000 et 69000. (I assume the dfu working with what I understand). During the DFU, it checks if there is enough place to du a DUAL_BANK. The problematic case is when the DFU assume there is enough space, so do dual_bank, add new app above the old one but write on the mesh config pages !! so it write until 6D000 for example. My mesh_config pages are "corrupted" and I have the assert on starte.
I confirm these observation by reading the flash directly.
If The size is bigger, it will conclude that dual_bank is not possible and do single bank. And that works !
So I have an issue with a range of application size -> when the dfu think that there is enough place because it does not take into account the mesh_config pages from 69000 to 6F000.

 

Here is all I already tried but not working : 

3) I tried to force SINGLE_BANK by putting NRF_DFU_SINGLE_BANK_APP_UPDATES = 1. the purpose here is to use less space and not write to 69000 before our applicaton size is very very big (what should not happen).
But this don't works. I have a "stopped by vector catch" error. I can not program the app after the bootloader.

4) I want to make sur the range 65000 to 72000 is not overwrite when doing DFU. I didn't find the way to do so.
I tried to modify the FLASH_PH_SIZE to 0x65000. the FLASH_SIZE=0x56000. But the DFU still overwrite on the problematic range when doing dual_bank. 

5) I also tried the DFU_APP_DATA_RESERVED in my application code and the NRF_DFU_APP_DATA_AREA_SIZE in the bootloader. I increased it because the doc says : This area will not be erased by the bootloader during a
// <i> firmware upgrade. The size must be a multiple of the flash page size.
But again it didn't works.

6) I always updated the "app_settings" for the bootloader. I understand that it is with this setting file that the DFU knows the size of the app,...

I tried some other little things, not usefull to mention now.

I don't find any more information on the web or the forum. I already tried solutions I saw but it does not work.

Can you help me please !?

The best solution would be to protect the "mesh_configuration" memory zone I think.
Or forcing singlebank dfu if first is not possible.

Waiting for your answer!

[ValentinL]

Can someone help me please !!??