Problem with flash_manager, NRF_MESH_ASSERT(p_manager->config.p_area[i].metadata.page_index < i);

[BvdP4Celsius]

We have a sudden problem with the flash_manager. The code stops at static uint32_t flash_area_build(flash_manager_t * p_manager), at line NRF_MESH_ASSERT(p_manager->config.p_area[i].metadata.page_index < i);

The system was working well for several day's. After a reboot, the system halts at the mentioned NRF_MESH_ASSERT.
I downloaded the memory area the p_manager.config.p_area is pointing to (0x000F0000)

The area is all 0xFF until 0x000F1000, There I can see settings we stored in flash.

In the debugger , I see the p_manager->config.p_area[i].metadata =
.metadata_len = 0x08
.entry_header_length = 0x04
.entry_len_length_bits = 0x10
.entry_type_length_bits = 0x10
.pages_in_area = 0x02
.page_index = 0x01
._padding = 0xffff

Any hints?

[tesc]

Hi,

There seems to have been some issues with my previous reply, in that it does not show on the web page. Attempting again, this is what I wrote:

The logs are consistent with an application image overwriting parts of the flash area used for persistent data by the Bluetooth Mesh stack.

You  cannot tell the size of the application from the size of the hex file, since the hex file encodes the data in hexadecimal (which uses more space) as well as adds some extra codes and checkssums to each line. However you should be able to tell from the hex file what regions are used by the application. The hex file format is thoroughly documented, for instance on the Intel HEX page on Wikipedia. If you have difficulties understanding the format and want me to have a look, then please create a private ticket and share your hex file there.

Other ways to figure out the application size are to look at the build output, or look at the map file, both of which should reveal application size (either directly or indirectly.)

Regards,
Terje

[ValentinL]

Hi,

thank you for your reply, i'll check for the size and come back to you if I need help.
Is it really a question of project size in your opinion?
What is the maximum size and how can I know it ?
I didn't add so much things compared to nordic examples ?

Kind regards

Valentin

[tesc]

Hi,

The nRF52840 has 1 MB of flash, and you need space for the SoftDevice, application data (including the pages used by the flash manager), and in the case of DFU two times the application (one for each of the running and the next version of the application.)

Regards,
Terje

[ValentinL]

Hello tesc 

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!

[tesc]

Hi,

ValentinL said:

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.

This one should have been the right approach. It is exactly what is described in the nRF5 SDK DFU bootloader documentation. Please make sure to set it high enough. If you tested this and you still got data pages overwritten, then the value might have been set too low.

Sometimes it may be caused by having ended up with using an older version of the bootloader where the value was not yet increased. In the case of bootloader upgrade, it is the bootloader currently on the device which decides how much applicaiton flash space to keep, not the one being upgraded to.

Regards,
Terje