Not able to send notifications and indications after bonding

[Ars Morozov]

Hello,

when I send notifications or indications to central device without bonding it works perfect. But after bonding they are not sent. I receive following logs when cetnral subscribes on my characteristics:
<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update
But when I send notification I get the following error codes - NRF_ERROR_INVALID_STATE


I use nRF52840-DK, SDK17.0.0,  my application based on ble_app_hrs_rscs_relay

Thank you in advance

[Karl Ylvisaker]

Hello,

But when I send notification I get the following error codes - NRF_ERROR_INVALID_STATE

Which function is returning with the NRF_ERROR_INVALID_STATE value?

Best regards,
Karl 

[Ars Morozov]

Hi Karl,

sd_ble_gatts_hvx() returns NRF_ERROR_INVALID_STATE

[Ars Morozov]

Ok,
but how can I check 2nd and 3rd conditions?

[Karl Ylvisaker]

Karl Ylvisaker said:

Notifications and/or indications not enabled in the CCCD

This happens if you try to notify a central that has not enabled notifications.
In your case, it sounds like you have enabled notifications, but you will need to verify that the particular CCCD is in fact enabled.

Karl Ylvisaker said:

An ATT_MTU exchange is ongoing

If a sd_ble_gattc_exchange_mtu_request has been made ( with return value NRF_SUCCESS ) you will need to wait for the BLE_GATTC_EVT_EXCHANGE_MTU_RSP to proceed.

If you are working out of the ble_app_hrs_rscs_relay example from the SDK, the 3. condition should be handled already, so my suspicion is on the 2nd condition.
Have you for instance created a custom characteristics that you would like to do notifications / indications on? In that case, the central will need to be told about this in advance, so it knows what to expect from this characteristic.

Best regards,
Karl

[Ars Morozov]

Karl Ylvisaker said:

This happens if you try to notify a central that has not enabled notifications.
In your case, it sounds like you have enabled notifications, but you will need to verify that the particular CCCD is in fact enabled.

How can I check this? 

Karl Ylvisaker said:

Have you for instance created a custom characteristics that you would like to do notifications / indications on? In that case, the central will need to be told about this in advance, so it knows what to expect from this characteristic.

Yes, I did. As I said it works perfectly without bonding.

[Ars Morozov]

I found mistake it was in my code. I have my own boolean variables, which indicates if notifications/indications enabled or no. I update them only during changing descriptor of characteristics. In case of bonding and after reset this variables are false and they reject any calls of hvx and handle this like INVALID_STATE error. I use it to overcome APP_ERROR_CHECK calls, because I also use it. 
Now I check desriptors of the chars inside connected event and update those boolean variables. In this way everything works perfect.
So, anyway thank you very much and sorry for false issue.

[Karl Ylvisaker]

Hello,

Ars Morozov said:

I found mistake it was in my code. I have my own boolean variables, which indicates if notifications/indications enabled or no. I update them only during changing descriptor of characteristics. In case of bonding and after reset this variables are false and they reject any calls of hvx and handle this like INVALID_STATE error. I use it to overcome APP_ERROR_CHECK calls, because I also use it. 
Now I check desriptors of the chars inside connected event and update those boolean variables. In this way everything works perfect.

This is exactly what the APP_ERROR_CHECK function is made to do, and how it should be used - alert you that you have gotten an unexpected return from a function. I am happy to hear that you were able to identify and resolve the issue! 

Ars Morozov said:

So, anyway thank you very much and sorry for false issue.

Do not worry at all, I am happy to help!

Please do not hesitate to open a new ticket if you should encounter any other issues or questions in the future.

Good luck with your development! :) 

Mvh.
Karl