This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Hello,

I am trying to transfer firmware packages in sequence (SD , BL & APP) to iOS device. I am using button less DFU without bonds. iOS device could able to transfer only one package after that the iOS is not able to detect the services in from BLE peripheral , whereas  in Android their is no issue. After going through forum I got to know that due iOS caching its preventing to proceed further. As we cant use bonding in our design, is their any work around to transfer all packages without out turning off/on bluetooth in iOS device. It would be helpful if any suggestions.

My Environment:

SDK: 15.3

Softdevice: 132 V6.1.1

SOC : nrf52382.

Parents
  • 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

Reply
  • 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

Children
  • Hello 

    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.

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

Related