Thanks for your answer. It works. And one more thing, if application calls this function, then will the BLE heap which is managed by kernel be emptied, I mean clear all current heap message?
The reason I want to call this function is that I want to disconnect actively when CUSTS1_VAL_NTF_CFM is not returned, to avoid heap crash. So I want to make sure this disconnection action can clear the accumulated heap.
If the answer was usefull, please accept the answer in order to be verified.
Each message that is send to the kernel, the kernel itself will free it (thats if it gets served), if the message is heading for the TASK_APP the task should free the message by returning KE_MSG_CONSUMED. Regarding the fact that you would like to disconnect when you dont get a CUSTS1_VAL_NTF_CFM, the message that you mentioned is send back as soon as the the notification has left the memory space and has entered the buffer in order to be send over the air, if you start accumulating messages in your heap that means that you dont follow the convention that you should first get a confirmation from the notification and then send an additional message. So the suggested way of handling that is to get a confirmation for the notification and then you send additional notification.
Now in case that you reach a point that you start accumulating messages in your heap as soon as you diconnect the buffers will be flushed and the messages that are still existing in your heap will get consumed, discarded actually since there will be no valid connection in order to sent the stored notifications.
Hi caiziee,
You can use the app_easy_gap_disconnect() function in order to instruct your peripheral to disconnect from your central.
Thanks MT_dialog
Hi, Dialog
Thanks for your answer. It works. And one more thing, if application calls this function, then will the BLE heap which is managed by kernel be emptied, I mean clear all current heap message?
The reason I want to call this function is that I want to disconnect actively when CUSTS1_VAL_NTF_CFM is not returned, to avoid heap crash. So I want to make sure this disconnection action can clear the accumulated heap.
Hi caiziee,
If the answer was usefull, please accept the answer in order to be verified.
Each message that is send to the kernel, the kernel itself will free it (thats if it gets served), if the message is heading for the TASK_APP the task should free the message by returning KE_MSG_CONSUMED. Regarding the fact that you would like to disconnect when you dont get a CUSTS1_VAL_NTF_CFM, the message that you mentioned is send back as soon as the the notification has left the memory space and has entered the buffer in order to be send over the air, if you start accumulating messages in your heap that means that you dont follow the convention that you should first get a confirmation from the notification and then send an additional message. So the suggested way of handling that is to get a confirmation for the notification and then you send additional notification.
Now in case that you reach a point that you start accumulating messages in your heap as soon as you diconnect the buffers will be flushed and the messages that are still existing in your heap will get consumed, discarded actually since there will be no valid connection in order to sent the stored notifications.
Thanks MT_dialog
Thanks, Dialog, it really helps me a lot.