When are BLE event observers called? Getting disconnection events as fast as possible?

RE: When are BLE event observers called? Getting disconnection events as fast as possible?

Andy — Tue, 08 Jan 2019 10:04:42 GMT

That's correct. Anyway, apparently, the app developers decided it wasn't a big deal so I'm not pursuing this further. In the case I need to do this in the future, I will try to call it from the app scheduler.

Thanks for your help as always :)

RE: When are BLE event observers called? Getting disconnection events as fast as possible?

Hung Bui — Tue, 08 Jan 2019 09:45:42 GMT

I assume you want to receive the last acknowledgment on the phone that the image has been transfer via I2C successfully before disconnection. If the DFU process can be finished successfully without the phone, from my opinion it's OK even though there is a disconnection before the last step finishes.
But please try to put the function to app scheduler , I think it would fix the issue.

RE: When are BLE event observers called? Getting disconnection events as fast as possible?

Andy — Mon, 07 Jan 2019 16:05:54 GMT

I actually thought that this function was already called from the main context using the app scheduler, but apparently, it isn't. It is only scheduled in case there's a flash operation pending. I think that if I force it to be scheduled, it should work then.

My bootloader is already heavily modified. I have an app that performs the DFU on my device. Apparently, from the app developer's perspective, it doesn't make sense that the DFU continues by itself if the app is not connected, even though the actual BLE transfer is done. The I2C erase, transfer and CRC check together still take about a minute after the BLE transfer.

I'm told that if the process continues, this behavior gives problems in case of disconnection/reconnection during DFU.

RE: When are BLE event observers called? Getting disconnection events as fast as possible?

Hung Bui — Mon, 07 Jan 2019 15:19:56 GMT

Most likely the command on_data_obj_execute_request_sched() will be called when there is an BLE event of an execute object write meaning you would have same priority level with the Disconnected event.

Why do you need to stop the operation when the device disconnect ?

You may want to think of using app_sched_event_put() to schedule the loop into main context. But you may need to modify the bootloader because I afraid it would reset before you can execute that loop (when dfu_observer() receives NRF_DFU_EVT_DFU_COMPLETED the bootloader will reset)

RE: When are BLE event observers called? Getting disconnection events as fast as possible?

Andy — Mon, 07 Jan 2019 12:54:09 GMT

I use the NRF52832 to perform the DFU over BLE for an STM32. The loop is basically writing the contents of the flash in bank 1 to the STM over I2C.

The loop is within the body of nrf_dfu_validation_post_data_execute(), which is called by on_data_obj_execute_request_sched(), a function queued and called by the app scheduler.

I don't know if the priority of the app scheduler is higher than the SD event stuff, but I doubt it.

RE: When are BLE event observers called? Getting disconnection events as fast as possible?

Hung Bui — Mon, 07 Jan 2019 12:35:04 GMT

Hi Andy,

Where do you have the loop ? Could you explain a little bit more what's the loop for ?

If you have a look at Section 7.2 in the S132 SDS v6.0 you can find the SoftDevice Event Notification is at priority level 6 .

If you have your loop at level 6 or higher (6-5-4 etc) the event wouldn't be able to preempt your loop. If you need to stay in a loop you should set the context level to priority lv 7 or in main.