DFU, caching & iOS

RE: DFU, caching & iOS

gkovelman_tap — Thu, 18 Jan 2018 12:25:51 GMT

OK, I got this working. Apparently, the SDK is not working well with DFU & multiple peers. Effectively, currently only the first peer is stored for SC indication.

The total changes I did:

ble_dfu_bonded.c: changed if (p_evt->params.peer_data_update_succeeded.data_id == PM_PEER_DATA_ID_GATT_LOCAL) to if (p_evt->params.peer_data_update_succeeded.data_id == PM_PEER_DATA_ID_SERVICE_CHANGED_PENDING) since the former was never triggered; only the latter.
ble_dfu_bonded.c: added break; before case PM_EVT_PEER_DATA_UPDATE_FAILED: since it'll enter the FAILED case upon any SUCCESS.
in main.c, in case BLE_DFU_EVT_BOOTLOADER_ENTER_PREPARE: stopped advertisement (setting ble_adv_on_disconnect_disabled with ble_advertising_modes_config_set(x)) since the iOS/android app SDK will reconnect to the FW before entering bootloader and cause app SDK errors.
gatt_cache_manager.c: removed fallthrough of case NRF_ERROR_INVALID_STATE in service_changed_send_in_evt(x) since this function is triggered after disconnection, after storing peers' data but before entering bootloader, which will drop the SC indication storage.
increased FDS_OP_QUEUE_SIZE since I saw a lot of FDS_ERR_NO_SPACE_IN_QUEUES which may cause peers' data to be discarded before entering bootloader

For now, it's working well. Couldn't find any bugs. Can somebody review the changes and possible effects on application behavior?

RE: DFU, caching & iOS

gkovelman_tap — Thu, 18 Jan 2018 07:57:45 GMT

but now there's a race in another place. in ble_dfu_buttonless_bootloader_start_prepare(), there's a connection termination, which didn't actually happen (to some degree). upon receiving callbacks from FDS about successful writes from gscm_local_database_has_changed(), the gatt_cache_manager's service_changed_pending_flags_check() is triggered, then seeing that it needs to send SC indication, but gscm_service_changed_ind_send(x) returns NRF_ERROR_INVALID_STATE since we already disconnected, which then removes the indication request (// CCCDs not enabled. Drop indication.).

I set a break in this case NRF_ERROR_INVALID_STATE so it doesn't removed the need for indication. Any comment on how would it affect the system? Any suggestion for a better solution?

RE: DFU, caching & iOS

gkovelman_tap — Wed, 17 Jan 2018 16:17:39 GMT

It passes the fallthrough (by mistake?) in the above code with an event p_evt->evt_id = PM_EVT_PEER_DATA_UPDATE_SUCCEEDED and p_evt->params.peer_data_update_succeeded.data_id = PM_PEER_DATA_ID_SERVICE_CHANGED_PENDING.

It looks like a race to store all of the peers' SC indication status in the flash until the reset to the bootloader. More likely until the 1st peer data is stored.

RE: DFU, caching & iOS

gkovelman_tap — Wed, 17 Jan 2018 15:48:19 GMT

Apparently, the code is hitting:

    case PM_EVT_PEER_DATA_UPDATE_FAILED:
    // Failure to update data. Service Changed cannot be sent but DFU mode is still possible
    err_code = ble_dfu_buttonless_bootloader_start_finalize();
    if (err_code != NRF_SUCCESS)
    {
        mp_dfu->evt_handler(BLE_DFU_EVT_BOOTLOADER_ENTER_FAILED);
    }

    break;

I'm investigating what's the reason for the failure

RE: DFU, caching & iOS

gkovelman_tap — Wed, 17 Jan 2018 15:00:14 GMT

Could it be that the SC indication is sent only to the first peer that ever connected? I'm seeing that the second peer doesn't receive the indication, but the first does

RE: DFU, caching & iOS

gkovelman_tap — Wed, 17 Jan 2018 12:34:22 GMT

@run_ar, using SDK14 from scratch, gscm_local_database_has_changed is called.

What are the effects of changing to bondless? Is it still buttonless DFU and no need for app/user intervention to perform DFU? and I'm guess that the link is not encrypted as well to the DFU is exposed.

RE: DFU, caching & iOS

gkovelman_tap — Wed, 17 Jan 2018 12:19:16 GMT

SC indication is working with iPad 2 Mini, iOS ver 10.3.3 and doesn't work with iPhone 7, iOS 11.2.2.

Any known issues with iOS 11?

RE: DFU, caching & iOS

run_ar — Wed, 17 Jan 2018 12:16:22 GMT

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.

RE: DFU, caching & iOS

gkovelman_tap — Wed, 17 Jan 2018 12:09:50 GMT

Continuing debugging, looks like the FW doesn't trigger SC indication at all. I've put breakpoints at gatts_cache_manager.c, line 359, right after sd_ble_gatts_service_changed call and a breakpoint at gatt_cache_manager.c, line 494, at BLE_GATTS_EVT_SC_CONFIRM case and none of them are hit.

Looks like the FW is not triggering indication. I'm wondering if iOS 11 has anything to do with that.

RE: DFU, caching & iOS

gkovelman_tap — Wed, 17 Jan 2018 10:59:31 GMT

attribute table didn't change in the app, but entering DFU and returning to app changes the table, as expected, I assume. No sniffer trace yet

RE: DFU, caching & iOS

run_ar — Wed, 17 Jan 2018 10:07:55 GMT

Are you changing the attribute table? And if so I assume you are sending a service changed indication when reconnecting to the peer? Do you have a sniffertrace so you can see if iOS starts the service discovery procedure when you send the service changed indication?