nrf52832 mesh bricks after OTA update

[Mr Sunshine]

Hello,

for clarification I use the nrf5_SDK_for_Mesh_v2.1.1.

After an OTA update (with use of the nRF toolbox app) the nrf52832 seem to be in a state of constant reboots. After some digging I see that the error happens during the mesh initialization in the "flash_manager_add()" function located at "flash_manager.c". In my case the when updating through OTA the "flash_area_is_valid()" will turn false. In addition the following is written in the function "If the area build fails, it's because we can't fit all the metadata in the action queue. Consider increasing its size."

What can I do to fix this issue? How can I increase this action queue size?  Am I looking in the right direction or am I just fixing a symptom instead of the cause?

[Mr Sunshine]

Edvin said:

Please try to check why the flash_area_is_valid()

how can I easily check this? It becomes quite a maze if I dig deeper in the function. 

In addition I have scanned the memory with nRF Connect and see this happening. Might this help to figure out the issue? What you see is one is made before the update which shows a blank space, and the other is after the update which shows almost no blank space.

[Edvin]

Have you tried to flash the new application manually? Does that work?

What is the free space (the grey area) in your screenshot to the left? Do you have the addresses? And what is the size of your new application? does it fit within that grey space?

Are you able to debug after the DFU?

 

Mr Sunshine said:

how can I easily check this? It becomes quite a maze if I dig deeper in the function. 

 Try to set a breakpoint in flash_area_is_valid(). Try to step a bit, and set new breakpoints to find out why the flash_area_is_valid() returns false.

Is metadata_is_valid() returning false? What is your page_count? Does it assert in any of these?

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

Which of these checks is it that fails? 

Remember that you may need to turn off optimization in order to debug this properly. 

Have you tried to port the application to a later SDK version? Is it reproducible there?

[Mr Sunshine]

Edvin said:

Have you tried to flash the new application manually? Does that work?

Flashing manually will fix the problem yes. But I want to update it through DFU. Currently some customers of us already have this product, so we don't want to call these back for a update if an OTA update is also possible. 

Edvin said:

What is the free space (the grey area) in your screenshot to the left?

I don't know what it is for, it was like this during development. I assumed it was the free space required for updates. All I know is that red is bootloader, black is bootloader settings, green is application and blue is soft device.

Edvin said:

Have you tried to port the application to a later SDK version? Is it reproducible there?

I have in the past but failed. Porting to another SDK isn't easily done, and from the experience it's probably easier to redo the project if I want to change the SDK.

I will respond later about flash_area_is_valid(). 

[Edvin]

Mr Sunshine said:

I don't know what it is for, it was like this during development. I assumed it was the free space required for updates. All I know is that red is bootloader, black is bootloader settings, green is application and blue is soft device.

 That is correct. But when you hover your mouse over the different fields. What is the end address of your application, and what is the start address of your FDS (the three green lines)?

And finally, what is the size of the application that you are updating to?

If the application image is too big to fit, perhaps it starts eating into the FDS pages. If so, you need to have a temporary middle application:

Original application -> DFU -> middle application -> DFU -> final application 

where the middle application is very reduced, much like the DFU example in the SDK.

Best regards,

Edvin

[Mr Sunshine]

Edvin said:

That is correct. But when you hover your mouse over the different fields. What is the end address of your application, and what is the start address of your FDS (the three green lines)?

I made the following images, I hope that these are clear enough:

for some clarification, the following colors are according to nRF Connect:

• first black is undefined
• second black is "MBR Paramters" 
• red is "bootloader"
• all of green is the "Application"
• blue is "Softdevice"
• orange is "MBR or Application"

It seems as if the DFU update overwrites some spaces of the Application.

Edvin said:

And finally, what is the size of the application that you are updating to?

if I look at the .hex file used to flash the original program the size is 939 KB. The new one, although not being flashed, is 864 KB. Reason why the new one is smaller is due to it being on Release configuration while toe original was on debug configuration. I don't know where I have to look to when looking for the file size for the DFU.

Edvin said:

If the application image is too big to fit, perhaps it starts eating into the FDS pages. If so, you need to have a temporary middle application:

I find this quite odd, current configuration of the devices I use is through a mesh with multiple nodes and one NUS to connect too with a Smart Device. This NUS is bigger in size than the nodes but doesn't show any issues during and after the OTA update while the nodes does. So if the image is too big than this should have surely shown on the NUS, but it currently doesn't. The NUS uses the same nrf52832 chip.