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

DFU, caching & iOS

Hi,

I know that this is a known issue, but I'm seeing caching issues often with iOS. I'm using S132 v5.0.0, SDK 14.0 against custom application with iOS DFU SDK and often I'm seeing that my device is unusable after DFU unless I toggle the bluetooth button in the iOS Settings window. If the DFU fails, then the device's displayed name continues to be DfuTarg unless bluetooth is toggled.

I'm using bonded devices, services changed characteristic is enabled in both app and BL.

Any reason why wouldn't the iOS discover the services correctly? Any solution for this issue? Workarounds?

I'll appreciate the help

Parents
  • Are you by any chance updating from an older SDK? Or are you starting from scratch with sdk 14?

    Assuming you are using buttonless, make sure the last this you do before starting the bootloader is set the service changed flag in the peer manager. See the ble_app_buttonless_dfu example: gscm_local_database_has_changed(); is called from the function ble_dfu_buttonless_bootloader_start_prepare();

    Have you considered not to use bonding for the bootloader? That way it will show up as a different device, so you avoid this problem all togheter.

Reply
  • Are you by any chance updating from an older SDK? Or are you starting from scratch with sdk 14?

    Assuming you are using buttonless, make sure the last this you do before starting the bootloader is set the service changed flag in the peer manager. See the ble_app_buttonless_dfu example: gscm_local_database_has_changed(); is called from the function ble_dfu_buttonless_bootloader_start_prepare();

    Have you considered not to use bonding for the bootloader? That way it will show up as a different device, so you avoid this problem all togheter.

Children
No Data
Related