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]

I might have found a solution. I altered in the sdk_config.h the NRF_DFU_SINGLE_BANK_APP_UPDATES variable from 0 to 1 and updated the bootlader separately through the DFU. After that the application update seems to function without the issues. Is single bank mode a wise way to go?

About your questions to the value of some variables, I'm afraid that what you are doing is primarily treating the symptoms instead of the cause. I think that during the OTA update the bootlader overwrites some of the configuration data which will cause the errors. 

Edvin said:

What is your DFU_APP_DATA_RESERVED defined as in sdk_config.h in your bootloader?

the sdk_config.h in the bootloader doesn't seem to have a DFU_APP_DATA_RESERVED, and I don't see anything similar in the file. I'm using the SDK 15.0.0. this version might lack it.

Edvin said:

I your case this size should reflect the distance from the bootloader area 0x70000 to the start of your flash manager (0x6B000), so try setting it to 20480 (or alternatively, 5*CODE_PAGE_SIZE).

How can I Alter this size withoud the DFU_APP_DATA_RESERVED in the sdk_config.h? 

[Edvin]

I see that in SDK15.0.0, the variable is called DFU_APP_DATA_RESERVED, and is defined in nrf_dfu_types.h.

Yes, NRF_DFU_SINGLE_BANK_APP_UPDATES set to 1 may prevent the issue to some degree, but if the application is big enough, the bootloader would start writing over your DFU area instead of throwing an error saying that the app is too big, so I would recommend you set the DFU_APP_DATA_RESERVED correctly.

The reason NRF_DFU_SINGLE_BANK_APP_UPDATES 1 works is that the bootloader will not try to use dual bank, meaning it will delete the application and store the application in the direct placement at first. In this case, it meant that the bootloader didn't use the area of the FDS pages. When it tried to use dual bank, it stored the application in the flash after the original application, because it thought it had space, since the flash manager pages was not protected by DFU_APP_DATA_RESERVED.

Dual bank is better if possible, because then you have a rollback in case something goes wrong during DFU (power loss). If not, the fallback after that would be that the device will start advertising as DfuTarg instead of running the previous application. No crisis, but it is a nice-to-have feature.

So the conclusion is: Set DFU_APP_DATA_RESERVED to protect your flash manager pages. It is a good safety to have, preventing bricked devices, like the update you currently had lead to (if you didn't have a programmer). 

Best regards,

Edvin

[Mr Sunshine]

I have altered the DFU_APP_DATA_RESERVED to be CODE_PAGE_SIZE * 5 as you suggested, and I set the NRF_DFU_SINGLE_BANK_APP_UPDATES  back to 0. The problem seems to be gone if I do a OTA update for first the bootloader and after the application, so thank you for that.

The issue isn't solved if I do an OTA update with a zip file that combines the bootloader, application, and softdevice altogether. It seems that I I use a combined zip that probably the application will be updated first instead of the bootloader. Might it be that I make a mistake when generating a new zip? The code I use is:

 nrfutil pkg generate new_DFU.zip --hw-version 52 --sd-req 0xA8,0xAF --sd-id 0 --softdevice softdevice.hex --bootloader-version 0 --bootloader bootloader.hex --key-file key_node.pem --application-version 0 --application application.hex

[Edvin]

When you do a BL + SD + APP update, you can generate this in one packet, but the process will be split in two. First it will update BL + SD in one go, because the bootloader requires that it always has a compatible SoftDevice.

When this is done, you can see that the device will reset briefly, and nrfutil/nRF Connect will reconnect to the device, and then perform the APP update.

What sort of issue do you see?

Try to only use one --sd-req (the old softdevice, that is already present on the nRF), and then you need to set the --sd-id to the new softdevice version.

But please describe what issue you have? Does the DFU complete? Are you talking about the flash_manager issue, or something else?

[Edvin]

I will leave for vacation today, so if the new problem is not related to the flash manager, I suggest you create a new ticket with a title that describes the issue.

BR,

Edvin