Why stack doesn't point to new value after sd_ble_gatts_rw_authorize_reply

RE: Why stack doesn't point to new value after sd_ble_gatts_rw_authorize_reply

Petter Myhre — Mon, 27 Nov 2017 21:20:43 GMT

I'm not sure why sd_ble_gatts_value_set() doesn't copy correctly, but you can try to call it will p_value set til NULL. Then only the length will be updated.

RE: Why stack doesn't point to new value after sd_ble_gatts_rw_authorize_reply

Petter Myhre — Mon, 27 Nov 2017 21:20:13 GMT

"Application traverses its queue and executes the write operations(memcpy)" is very unclear. I recommend using sd_ble_gatts_value_set() to set the attribute values, as it seems you are doing now. So variant #1 and variant #2 are very similar actually. I have reported this as a documentation improvement.

When you reply with sd_ble_user_mem_reply(p_ble_evt->evt.gattc_evt.conn_handle, NULL); you have to set the attribute values, the SoftDevice will not have any place to store the values you reply to sd_ble_gatts_rw_authorize_reply() until EXEC_WRITE_REQ_NOW is received.

.update has to be 1 when type is BLE_GATTS_AUTHORIZE_TYPE_WRITE

.p_data is actually sent back to the peer, see "Prepare write response" in the Bluetooth spec for more information.

RE: Why stack doesn't point to new value after sd_ble_gatts_rw_authorize_reply

Miro Petrak — Fri, 24 Nov 2017 09:28:19 GMT

Yes i've checked the length and it was ok (it should be because vector tracks it's size automatically)

RE: Why stack doesn't point to new value after sd_ble_gatts_rw_authorize_reply

Petter Myhre — Mon, 13 Nov 2017 16:01:39 GMT

Sorry the late replay. Could you edit your question and include your answer/update below? Just to keep things clean. I'm not sure why you data is changed. Have you checked the length you provide when calling sd_ble_gatts_value_set()?