DFU bootloader and FDS

RE: DFU bootloader and FDS

Edvin — Tue, 15 Sep 2020 09:09:24 GMT

[quote user="Andrea Lombardo"]So this does it mean that the SDK13 BL tries to perform dual bank not considering the FDS storage area?[/quote]

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?

[quote user="Andrea Lombardo"]Any other idea to force the bootloader to run single page (without reprogramming the BL) instead of artificially increase the size of the application?[/quote]

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.

[quote user="Andrea Lombardo"]Any idea why we experience bonding information loss during bootloader upgrade?[/quote]

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).

RE: DFU bootloader and FDS

Andrea Lombardo — Tue, 15 Sep 2020 04:39:59 GMT

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

RE: DFU bootloader and FDS

Edvin — Mon, 14 Sep 2020 14:07:25 GMT

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.

[quote user=""]Neverthless the bootloader runs a dual bank page update, corrupting the area. At new startup the FDS_Init fails because no pages are available.[/quote]

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