Toggle Notification Issues - NRF_ERROR_BUSY & Loss of Handles - Need Recommendations

[KLui]

Hi,

I wrote my codes to toggle notification on and off using a button using nRF25840-DK and sdk v15. The task looked a simple one; however, I hit some issues such as error 17 ( NRF_ERROR_BUSY) and the loss of handles. Attached screen capture showed the result after fixing the issues. I would like to share it and get comments from others to see if there is any smarter way to handle the issues. Remark: the battery levels were just adc measurements in mV without any voltage tied to the adc port and the values were insignificant to the issues.

In order to fix the busy issue, I had to retry enabling or disabling the notification at the coming write event according to other postings in DevZone. This issue could be easily solved when disabling notification. However, there was another big issue when I was enabling again after disabling notification because the event status stepped out of notification event and went to no where. After chopping my enabling operation into pieces in my program, I could enabling it again. I tried on my custom services first and implemented the same process in battery level notification. My custom service worked smoothly in re-enabling notification; however, I hit another issue of losing my handles in the battery re-enabling notification. The handles were re-initialized from zeros and could not be restored back to the previous ones. I solved this issue by saving the handles and restoring them when enabling the notification again. My custom service could re-stored the handles properly after they were re-initialized from zeros. The codes for cccd write in my custom service was different compared with the codes used in battery level notification.

I want to get comments from others below:

1. Did I do it right to handle the error busy issue by re-trying at write event?

2. Why was there no loss of handles in my custom service but battery notification had the loss during re-enabling notification? Is there any best way to restore the handles after they are lost?

[Kenneth]

1. If you receive an NRF_ERROR_BUSY the api do provide a recommendation on handling of this error:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s113.api.v7.2.0/group___b_l_e___g_a_t_t_s___f_u_n_c_t_i_o_n_s.html#ga313fe43c2e93267da668572e885945db

"For BLE_GATT_HVX_INDICATION Procedure already in progress. Wait for a BLE_GATTS_EVT_HVC event and retry."

2. Not sure if I understand the question. But handles are typically located at the same place, so you can store them away and re-use them if you for instance support bonding.

[KLui]

There may be an misunderstanding. I mentioned the issues were on the BLE central and not the peripheral. I used buttons to control from central to enable or disable notifications.

1. I understand the cause of the NRF_ERROR_BUSY. Once it happens and the err check will need a reset to handle the situation; and that is my question how to handle this type of situation.

2. As I stated in my post, the program stepped out the notification event and it goes no where. I have to implement an additional cccd write statement to re-enable  the notification somewhere in the program and that caused the loss of handles.

[Kenneth]

KLui said:

1. I understand the cause of the NRF_ERROR_BUSY. Once it happens and the err check will need a reset to handle the situation; and that is my question how to handle this type of situation.

You don't need to reset, it may be that you are doing that now, but you can choose to change the behavior that if error code is NRF_ERROR_BUSY, then don't assert, but instead: "For BLE_GATT_HVX_INDICATION Procedure already in progress. Wait for a BLE_GATTS_EVT_HVC event and retry." In other words don't call APP_ERROR_CHECK() if error code is NRF_ERROR_BUSY.

Kenneth