About the use of sd_ble_gatts_rw_authorize_reply()

Through nordic official routine ble_app_cgms, I found that I can achieve the effect I want. Use sd_ble_gatts_rw_authorize_reply() to confirm whether you have permission, and then sd_ble_gatts_value_set() to update the attribute value. I used to use "write data", so the value has not been updated, and now I use "authorize_request data" to find that it can be updated.

	case BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST:
	{
		if(pBleEvent->evt.gatts_evt.params.authorize_request.type == BLE_GATTS_AUTHORIZE_TYPE_WRITE)
		{
			ble_gatts_rw_authorize_reply_params_t rw_authorize_reply_params;
			memset(&rw_authorize_reply_params, 0, sizeof(rw_authorize_reply_params));
			
			rw_authorize_reply_params.type = BLE_GATTS_AUTHORIZE_TYPE_WRITE;
			if(GetUnlockFlag())	 /**< Get locked or unlocked status */
			{
			    ble_gatts_value_t gatts_value;
                memset(&gatts_value, 0, sizeof(gatts_value));
                
				rw_authorize_reply_params.params.write.gatt_status = BLE_GATT_STATUS_SUCCESS;	 /**< write permission */
				rw_authorize_reply_params.params.write.update = 1;
				err_code = sd_ble_gatts_rw_authorize_reply(pBleEvent->evt.gatts_evt.conn_handle, &rw_authorize_reply_params);
			    
                gatts_value.len     = pBleEvent->evt.gatts_evt.params.authorize_request.request.write.len;
                gatts_value.offset  = 0;
                gatts_value.p_value = (uint8_t*)(pBleEvent->evt.gatts_evt.params.authorize_request.request.write.data);
                
                sd_ble_gatts_value_set(BLE_CONN_HANDLE_INVALID, pBleEvent->evt.gatts_evt.params.authorize_request.request.write.handle, &gatts_value);
			}
			else
			{
				rw_authorize_reply_params.params.write.gatt_status = BLE_GATT_STATUS_ATTERR_WRITE_NOT_PERMITTED; /**< no write permission */
				rw_authorize_reply_params.params.write.update = 0;
				err_code = sd_ble_gatts_rw_authorize_reply(pBleEvent->evt.gatts_evt.conn_handle, &rw_authorize_reply_params);
			}
		} /* if */
	}
	break;

Hi,

While you could do it this way, you should be able to set the new value through the call to sd_ble_gatts_rw_authorize_reply call, as you tried initially. However I don't know if pointing to the data from the event will work. You may have to copy the data to a (static) buffer controlled by the application, instead of using the memory of the event structure (which the SoftDevice will repurpose.) In any case you check the returned err_code by adding a line "APP_ERROR_CHECK(err_code);" as that will reveal if something is wrong with the API call itself.

Regards,
Terje

That is to say, I can directly use the data in sd_ble_gatts_rw_authorize_reply() to update my attribute value. Without adding sd_ble_gatts_value_set() later to set the attribute value?

That is to say, I can directly use the data in sd_ble_gatts_rw_authorize_reply() to update my attribute value. Without adding sd_ble_gatts_value_set() later to set the attribute value?

Hi,

Yes, see the ble_gatts_authorize_params_t struct reference, and the GATTS Write Request with Authorization MSC.

By checking the return code from the call to sd_ble_gatts_rw_authorize_reply(), you should see if there is something wrong with the way you called that function previously. (The error codes and when they get returned is listed in the funciton's API documentation)

Regards,
Terje

Thanks for your reply, I have edited it.

Hi,

To clarify, what I mean is to always check the error code, like this:

err_code = sd_ble_gatts_rw_authorize_reply(pBleEvent->evt.gatts_evt.conn_handle, &rw_authorize_reply_params);
APP_ERROR_CHECK(err_code);

The APP_ERROR_CHECK macro will reset (for release builds) or enter infinite loop (for debug builds) and log an error message with debug info.

That way for a debug build you can see from log (RTT or UART, depending on configuration) or during debug session what went wrong. For release builds, on the other hand, which are intended for final products, the device resets. This makes sense since when an unknown error happens it is better to reset (into a known state) than to continue (in an unknown state.)

In most cases one would just use the APP_ERROR_CHECK on the returned value, and not check for any values manually first. However if there are known error return values that you know how to handle programmatically (or can safely ignore), then you should check the return value in code first, and only do APP_ERROR_CHECK for values that cannot be safely ignored or handled otherwise. You may find a few examples of that in the SDK, but you will see that in most instances the APP_ERROR_CHECK is called directly on the return value.

Regards,
Terje