DFU bootloader and FDS

[Andrea Lombardo]

Hi, 

we have in production an old application developed with SDK13. The application size is growing and with the last update we discovered that during DFU bootloader update, the area reserved for FDS gets corrupted.

In bootloader the area appears to be reserved with 

#define NRF_DFU_APP_DATA_AREA_SIZE 12288

and the application is using just 3 1024 bytes pages 

#define FDS_VIRTUAL_PAGES 3

So information look to be coherent.

Neverthless the bootloader runs a dual bank page update, corrupting the area. At new startup the FDS_Init fails because no pages are available.

I have seen it clearly, dumping the memory before and after the DFU procedure. After the DFU procedure the pages that were reserved to FDS have been filled with the object code of the just uploaded application.

The result is not only that the app data is lost, but also the new application version is stuck, as we did not properly managed the FDS_init error.

The workaround we found was to artificailly increase the new application size, forcing the bootloader to run a single page update. Doing that the FDS pages are reserved and wverything works.

We are experiencing something that I suspect could be similar with a more recent SDK (17). In this case after the DFU update we loose bonding data. I suspect could be a similar issue as my understanding is that bonding data are stored thanks to FDS:

Should the setting of NRF_DFU_APP_DATA_AREA_SIZE  be enough to protect the area? What are we doing wrong?

Thank you

Andrea

[Edvin]

What SDK is the bootloader with NRF_DFU_APP_DATA_AREA_SIZE defined from? I can't see anything like that in SDK13.x.0.

I'll use SDK17 for reference for now.

12288 = 3*CODE_PAGE_SIZE, so that should be enought.

 

Neverthless the bootloader runs a dual bank page update, corrupting the area. At new startup the FDS_Init fails because no pages are available.

 What does the bootloader that is currently flashed look like? Does it have any app_protect functionality? What SDK is it from? Does it only support dual bank, or should it switch over to single bank if there is no space for two applications?

BR,

Edvin

[Andrea Lombardo]

Yes, you are right.

As I mentioned we have two applications and we are experiencing similar problems. So I put them together, but I got confused.

OLD APPLICATION - SDK 13

The bootloader of the old application is basically the bootloader_secure_ble project in SDK 13 and, yes, you are also right when you say that there is no NRF_DFU_APP_DATA_AREA_SIZE  definition in the SDK 13 bootloader. 

So this does it mean that the SDK13 BL tries to perform dual bank not considering the FDS storage area? Deciding only on firmware size.

Any other idea to force the bootloader to run single page (without reprogramming the BL) instead of artificially increase the size of the application?

NEWER APPLICATION - SDK17

Ok, good to know that we did right in defining the NRF_DFU_APP_DATA_AREA_SIZE. Any idea why we experience bonding information loss during bootloader upgrade? Anyway, If not, we will investigate more on this and we will get back to you. As I mentioned, it does not happen 100% of the time.

Am I right if I say that all bonding info are stored in the FDS area?

Thanks

Andrea

[Edvin]

Andrea Lombardo said:

So this does it mean that the SDK13 BL tries to perform dual bank not considering the FDS storage area?

 Actually, I see that there is something in nrf_dfu_utils.c and nrf_dfu_types.h.

nrf_dfu_utils.c, line 540:

uint32_t free_size =  DFU_REGION_TOTAL_SIZE - DFU_APP_DATA_RESERVED;

Where DFU_APP_DATA_RESERVED is defined in nrf_dfu_types.h, and by defatult set to 3 pages. What is this set to in your case? If it is set to 3 pages, then can you try to debug to see what happens in this function: nrf_dfu_find_cache(). What bank does it select?

Andrea Lombardo said:

Any other idea to force the bootloader to run single page (without reprogramming the BL) instead of artificially increase the size of the application?

 You have some options:

Either, you can update to a very small application. I am not sure if the bootloader in SDK13 always uses the same address for the second bank, or if it sets the second bank right above the end of the first application.

The other option is to update to a new bootloader that has the app data reserved functionality working properly.

Andrea Lombardo said:

Any idea why we experience bonding information loss during bootloader upgrade?

 What do you update from and to? Sorry if this is really clear, but I am not sure. Do you upgrade from SDK13 to 17? Do you update the softdevice as well? Is the new application using the peer manager? Is the old application using the peer manager as well, or does it use device_manager?

Is your bootloader set to use bonding or not? (If it is not, then I don't think the solution is to turn that on. It may not do exactly what you expect. This is used to require bonds from the device that is performing DFU).