I basically have this code:
while (...) { // A
while (BLE_STATUS_INSUFFICIENT_RESOURCES == aci_gatt_update_char_value(...)) { // B
osDelay(10);
}
}
while (BLE_STATUS_INSUFFICIENT_RESOURCES == aci_gatt_update_char_value(...)) { // C
osDelay(10);
}
The upper loop (A) is sending sequential notifications to a characteristic (B).
The lower part is sending a final indication to a different characteristic (C).
On the device that has subscribed to the notifications from B and indications from C, the indication from C seems to arrive earlier than the last notifications from B.
In the end, all notifications are received, but the order is off compared to the code. I was expecting the BLE stack to have an internal message queue, meaning the indication would not be processed until the last notification was sent. But this does not seem to be the case.
If B sends 96 notifications, the order I receive may be:
B1, ..., B40, C, B41, ..., B96
Is there any way to ensure C can only be received after B96 was sent, either by delaying the code, checking the remainder of enqueued notifications, receiving an event when the notification was sent (not received, I know notifications aren't acknowledged), reducing a buffer to 1 message to guarantee any call will return with INSUFFICIENT_RESOURCES until the data was sent?
Best regards
Chris
