assert flash Memory Metadata not aligned after FOTA

[Simsim]

Hi There

I run a NRF52840 with the MESH SDK, and use the Flash manager provided.

After some time i would like to update the Device over FOTA this ends in a Assert on booting with the new firmware at the point flash_manager.c Line 256

NRF_MESH_ASSERT(p_manager->config.p_area[i].metadata.pages_in_area == p_manager->config.page_count);

when erase the full mcu this assert is not showing up due no existing data.

In the best case i can keep the data in the Fields, when not how to erase the Flash bevore or at the FOTA?

Regards Simon

[Hieu]

Hi Simon,

Our apologies, this is something we should have done first, but I would like to check, are you working on a new project?

If so, I strongly recommend using the nRF Connect SDK (NCS) instead. The nRF5 SDK is in maintenance mode and is not recommended for new project. We also provide online course here to help you ramp up quickly with NCS: Nordic Semiconductor Online Learning Platform - Nordic Developer.

Notably, the DFU feature in the nRF5 SDK for Mesh is experimental and contains some flaw. It is also proprietary. Meanwhile, NCS supports a new Mesh DFU solution, which is now specified by the Bluetooth SIG in the Mesh Device Firmware Update Model spec.

Hieu

[Simsim]

Hi Hieu

It is an old Project, what in the first instance was rollout 3 Years ago, to update the Devices in the field i would like to provied a new version over FOTA.

As far i know, the issue arises also with the NCS when flashing on (the existing) Mesh SDK Projekt over FOTA or not "erase all" when flashing over jlink.

The Issue is not from the DFU itsleve, it comes after booting the application with a different flash configuration than present in the flash. 

The following ilustration what is happening, While checking Flash Address FC there is a missmatch in the configuration, and the Assert arrises this is ok so far. now i would like to avid the asserting with the ideas in the upper posts.

I just wondered how you would propperly handle this.

Flash Address	Old	New
0x00000FE	Mesh Data	Mesh Data
0x00000FD	App Data 1	App Data1
0x00000FC	App Data 2	App Data1.1 <- here it asserts
0x00000FB	App Data 3	App Data 2
0x00000FA	empty	App Data 3
0x00000F9	empty	App Data 4

Regards

Simon

[Hieu]

Hi Simon,

I understand now. Then it is what it is.

Generally, we advise against changing the memory layout, unless you have got reserved sections for that purpose.

May I know the details behind how you are sure that the assert happened at the App Data 1.1 section?

What is your full memory layout, including the main application slots, before and after this change?

Regards,

Hieu

[Simsim]

Hi Hieu

in the post 8 day ago i tried to show where the assert happend and what the log output writes, i had added this part after the first version was deployed in the field, so far i expected some issue in this code area.

The compared memory layout below (the Bootloader was not shown in this view)

Old Version flash page end at 0x000EF000	New Version flash page end at 0x000EE000

[Hieu]

Hi Simon,

I'm just giving a short ping today to let you know I am still looking into this. My knowledge of the old solution is rusty, and digging has been a bit time consuming.

[Hieu]

Hi Simon,

The short version is that, if I understand correctly, you are trying to expand the total flash area the application can store data in, and you do so by modifying the existing flash_manager instance.

That will not work. You can however create a new flash_manager instance to store any new data in.

Is that an option for you? Or do you need to increase the size of the data already stored?

If I misunderstood anything, or if that doesn't work for you, below is the long answer, with some questions from me.

1. Regarding memory layout

Simsim said:

Flash Address	Old	New
0x00000FE	Mesh Data	Mesh Data
0x00000FD	App Data 1	App Data1
0x00000FC	App Data 2	App Data1.1 <- here it asserts
0x00000FB	App Data 3	App Data 2
0x00000FA	empty	App Data 3
0x00000F9	empty	App Data 4

1. A. I assume you mean the address as 0xF*000 here, rather than 0x00000F*.

1. B. How are you certain that the Mesh data is only from 0xFE000? Did you use configuration like ACCESS, DSM, and NET_FLASH_AREA_LOCATION configurations?
Or did you control the flash placement somehow?
Or did you check with mesh_config_backend_flash_usage_get()?

1. C. How are you using the Flash Manager module?

2. Regarding your description on 26 Aug:

Simsim said:

I found many beginners struggling when loading different exampels without --eraseall of the mcu the get stuck in the asserts. 

Yes, the past storage value might not make sense to new application, causing assert.

However, for the case of DFU, if you don't change the Mesh stack features, then the old data should be compatible with the new firmware.

Even if you do change the Mesh stack features, in a lot of case, the data is still compatible.

Simsim said:

I would like to build a software version which can be uploaded over FOTA with a partial blank flash sector or check the nvmc for a flash config id which i can compare with my actual if it match i will proceed, otherwise i had to erase all the flash to ensure the data integrity.

Right, and,

2.A. What have you done to attempt at this? Or is this something you are having trouble with?

Simsim said:

mesh_stack_config_clear() is alredy implemented and working as expected.

while taking the mesh_stack_config_clear() as sample, there i discovered that the entry will be first overwritten and then cleared, otherwise i will find the metadata of the depreciated flash entry and assume the flash is valid?

2.B. Could you please elaborate what you are doing here?

Simsim said:

The assert i could reproduce is when the pagecount is increased so that the memory layout will be shiftedfor the following entries.

Code line 10 assert at flash_manager.c line 256

2.C. Could you please get me the full call stack when the assert happens, using the debugger?

Simsim said:

Can you short summarise how to erase properly the user flash  entries/pages (without knowing the old layout).

I am having issue figuring out how the Mesh stack can avoid having the application mess with its flash_manager area. It seems like there is no defense in place at all, and the application must use mesh_config_backend_flash_usage_get() to see that and avoid it on their own.

So, to answer this, I need you to know the information I am asking about above. But to give you some initial information, you will use either flash_manager_remove() or flash_manager_entry_invalidate().