On BLE data transfer error BLE service changes its state to error, while transmission can only be performed if BLE is in Idle state. Currently the idea is client should query BLE Service state trough BT_UUID_SETTINGS_STATUS GATT characteristic and reset it using Abort command sent over BT_UUID_SETTINGS_CONTROL GATT characteristic.
There are currently 2 problems to be resolved:
-
RequestRead does check if BLE Service state is idling before initiating a transfer, but StartWrite doesn't. Add state validation logic to StartWrite command handler.
-
It's not obvious if transaction failed or it takes time. Review possible options to make it more deterministic. I think maybe sending status updated or error notification can be a good idea through BT_UUID_SETTINGS_STATUS GATT characteristic. Currently only transaction updates are transferred through BT_UUID_SETTINGS_STATUS, such as StartRead and EndRead. Add StatusError notification which will be sent if status changes to error, workflow for a client after that would be to query Settings Service Status and send Abort command to reset status.
On BLE data transfer error BLE service changes its state to error, while transmission can only be performed if BLE is in Idle state. Currently the idea is client should query BLE Service state trough BT_UUID_SETTINGS_STATUS GATT characteristic and reset it using Abort command sent over BT_UUID_SETTINGS_CONTROL GATT characteristic.
There are currently 2 problems to be resolved:
RequestRead does check if BLE Service state is idling before initiating a transfer, but StartWrite doesn't. Add state validation logic to StartWrite command handler.
It's not obvious if transaction failed or it takes time. Review possible options to make it more deterministic. I think maybe sending status updated or error notification can be a good idea through BT_UUID_SETTINGS_STATUS GATT characteristic. Currently only transaction updates are transferred through BT_UUID_SETTINGS_STATUS, such as StartRead and EndRead. Add StatusError notification which will be sent if status changes to error, workflow for a client after that would be to query Settings Service Status and send Abort command to reset status.