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

[Andy]

Hi,

I'm working on a custom bootloader based on the one included with SDK 15.

I have a blocking method (i.e. while loop) that runs at the end of the transmission of all the data over BLE. I want to break out of the while loop and throw an error if the device is disconnected while the loop is being executed.

My problem is that ble_evt_handler is not getting called while I'm running that method. My guess is that it is only called after I call sd_app_evt_wait(), but I'm not sure about it. If this is the case, calling it inside the loop wouldn't work for me because I want the loop to be executed as fast as possible. I read in the documentation that sd_app_evt_wait() returns immediately if there's a pending interrupt. Is it possible to fake a pending interrupt?

Another thing I read I could do is to call sd_ble_gap_adv_start() and check the return code. It throws NRF_ERROR_INVALID_STATE if you are already advertising or NRF_ERROR_CONN_COUNT if you are in a connection (and cannot start another advertiser). But this is ugly I think.

How could I go about my problem? Thanks for your help.

[Hung Bui]

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. 

[Andy]

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.

[Hung Bui]

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)

[Andy]

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.

[Hung Bui]

 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. 

[Andy]

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 :)