Issue in sequential update of firmware packages (SD + BL + APP) in iOS without bonds?

RE: Issue in sequential update of firmware packages (SD + BL + APP) in iOS without bonds?

Aleksander Nowakowski — Thu, 25 Jun 2020 15:08:00 GMT

If both the app and bootloader are to have the same Mac, you need to solve caching issue. On iOS it's enough to enable Service Changed characteristic. On Android.. I think it clears the cache in right moments, but if not, you'll have to add one line of code to your custom dfu Android lib.

RE: Issue in sequential update of firmware packages (SD + BL + APP) in iOS without bonds?

deepu301 — Thu, 25 Jun 2020 11:34:16 GMT

Hello Aleksander Nowakowski

Thanks for your reply. As I have commented below line in file bootloader\ble_dfu\nrf_dfu_ble.c in order to use same MAC ID in application and DFU mode which led to caching in iOS device. After commenting it works fine with +1 incremented MAC ID now can load all three files.

uint32_t ble_dfu_transport_init(nrf_dfu_observer_t observer)
{

....

....

//err_code = gap_params_init();
// VERIFY_SUCCESS(err_code);

}

Now the question is, in our project we might have multiple devices at a time close by and we are using custom MAC range for application if it increment there might have collision of MAC-ID with other device in vicinity.

Is it possible to use default MAC ID in DFU mode rather that incrementing application MAC +1. If possible how to change DFU MAC to default. Will this have impact on iOS and Android nordic dfu library.

RE: Issue in sequential update of firmware packages (SD + BL + APP) in iOS without bonds?

Aleksander Nowakowski — Tue, 23 Jun 2020 13:15:57 GMT

Hello!

This should work, unless you had Service Changed characteristic disabled in the previous version of the bootloader and try to enable it in the new one. The DFU bootloader, when triggered using buttonless update without bonds uses address +1. All services are cached during the first update. After upgrading SD+BL, the new bootloader restarts and it will use the same address as before (+1). All services cached before should be exactly the same after in the new bootloader. If at least one of your DFU bootloader didn't have SC enabled, you can never enable it in any future version.

TL;DR:

If you had SC enabled in the previous DFU bootloader - caching should not be a problem, as iOS won't cache.

If you didn't have SC enabled in at least one previous version - make sure you will never enable it in any future version.

I hopes I guessed the cause of your problem. Otherwise, you didn't have SC characteristic in the "previous" bootloader and you're adding some other services/characteristics to the bootloader, which is also not allowed. I can't find any other option that would cause problem in this scenario.

BR, Aleksander