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?

[Edvin]

Hello,

 

After an OTA update (with use of the nRF toolbox app) the nrf52832

 This means that you are using a BLE bootloader, and not the mesh bootloader, right?

I don't remember what combination, but I remember that there was one Mesh SDK that used a version of the nRF5 "normal BLE" SDK where this combination was not compatible with one another. The reason was that the nRF5 SDK used a new method of storing the bootloader address, which the Mesh SDK didn't check for.

When you have programmed the bootloader and performed the OTA DFU (or alternatively you can generate and flash bootloader settings using "nrfutil settings generate (--help)" if it is tedious to do this every time). What is the return value of BOOTLOADERADDR() in flash_manager_defrag.c. Is it 0xFFFFFFFF or the actual bootloader address?

BR,

Edvin

[Mr Sunshine]

hello Edvin,

Edvin said:

This means that you are using a BLE bootloader, and not the mesh bootloader, right?

Yes it uses BLE for updates. The system can be set in a separate DFU mode when using.

Edvin said:

When you have programmed the bootloader and performed the OTA DFU (or alternatively you can generate and flash bootloader settings using "nrfutil settings generate (--help)" if it is tedious to do this every time). What is the return value of BOOTLOADERADDR() in flash_manager_defrag.c. Is it 0xFFFFFFFF or the actual bootloader address?

I don't really understand what you are saying. Where is this "flash_manager_defrag.c" is this a separate file? 

I have generated the bootloader settings file if you are interested in that, but I cannot see this BOOTLOADERADDR() you are mentioning in this file. below the contents of the bootloader settings file:

:020000040007F3
:10E00000445500E70100000000000000000000008F
:10E01000000000000000000020F40100C4627BB397
:10E0200001000000000000000000000000000000EF
:10E0300000000000000000000000000000000000E0
:10E0400000000000000000000000000000000000D0
:0CE05000000000000000000000000000C4
:10F00000445500E70100000000000000000000007F
:10F01000000000000000000020F40100C4627BB387
:10F0200001000000000000000000000000000000DF
:10F0300000000000000000000000000000000000D0
:10F0400000000000000000000000000000000000C0
:0CF05000000000000000000000000000B4
:00000001FF

I hope this helps.

[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

[Mr Sunshine]

thank you for your time, I'll create a new ticket.

Have a great holiday.