INVALID_PARAM for sd_ble_gatts_rw_authorize_reply

[Gordon]

Hi,

I've recently hit an issue where sd_ble_gatts_rw_authorize_reply in my code returns INVALID_PARAM when I try and write a long set of data to a characteristic using the NRF Connect app. Shorter data works perfectly.

It's using totally standard code from Nordic's examples:

  case BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST:
  {
      ble_gatts_evt_rw_authorize_request_t  req;
      ble_gatts_rw_authorize_reply_params_t auth_reply;

      req = p_ble_evt->evt.gatts_evt.params.authorize_request;

      if (req.type != BLE_GATTS_AUTHORIZE_TYPE_INVALID)
      {
          if ((req.request.write.op == BLE_GATTS_OP_PREP_WRITE_REQ)     ||
              (req.request.write.op == BLE_GATTS_OP_EXEC_WRITE_REQ_NOW) ||
              (req.request.write.op == BLE_GATTS_OP_EXEC_WRITE_REQ_CANCEL))
          {
              if (req.type == BLE_GATTS_AUTHORIZE_TYPE_WRITE)
              {
                  auth_reply.type = BLE_GATTS_AUTHORIZE_TYPE_WRITE;
              }
              else
              {
                  auth_reply.type = BLE_GATTS_AUTHORIZE_TYPE_READ;
              }
              auth_reply.params.write.gatt_status = APP_FEATURE_NOT_SUPPORTED;
              err_code = sd_ble_gatts_rw_authorize_reply(p_ble_evt->evt.gatts_evt.conn_handle,
                                                         &auth_reply);
              APP_ERROR_CHECK(err_code);
          }
      }
  } break; // BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST

edit: Simply download the Nordic UART example firmware and follow the steps below. It has exactly the same problem

It's using one service - the standard Nordic UART using Nordic's NUS library, but I'm doing that with Espruino. It's trivial to reproduce - simply download the nrf52832dk hex file from www.espruino.com/.../, connect with nRF Connect on Android, and then go to the NUS RX characteristic and send one really big packet - it reboots with an error.

(You can see the error better if you connect via the USB UART at 9600 baud first and send Serial1.setConsole(1), then connect with nRF Connect, then send the big packet)

Any ideas what I might be doing wrong? I'm using s132_nrf52_3.0.0_softdevice.hex (SDK 12.1) at the moment. I know that's not the current one but it'll be a pain to change.

If I create a second service and characteristic and write a lot of data into that I get exactly the same problem as well.

thanks!

[bjorn-spockeli]

It sounds like you're ending up in the app_error_handler after checking an error code with APP_ERROR_CHECK, which leads to a reset of the device. Are you able to debug the application and identify which function that returns an error code that causes APP_ERROR_CHECK to assert?

[Gordon]

Yes, it's sd_ble_gatts_rw_authorize_reply in the code above that returns the error

[bjorn-spockeli]

If you're using S132 v3.0.0, then you're probably using the code from the ble_app_uart example in SDK v12.x.0. In this example the size of the RX characteristic is set equal to BLE_NUS_MAX_DATA_LEN which is defined as (GATT_MTU_SIZE_DEFAULT - 3), where GATT_MTU_SIZE_DEFAULT is 23, i.e. 20 bytes. So if you're attempting to send more than 20 bytes of data, then this could be the cause. However, neither the RX or TX char has the authorization properties set, i.e. attr_md.rd_auth or attr_md.wr_auth set to 1, so I guess you have modfied this in the code? Otherwise you would not get the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST event.

[Gordon]

I've just checked and using examples/ble_peripheral/ble_app_uart/hex/ble_app_uart_pca10040_s132.hex you can do exactly the same. This is scary - sending a large string from nRF Connect causes UART Start to be printed (which only happens if the whole device restarts) - so it's not specific to my application at all - it looks like anything based on Nordic UART example can be restarted remotely!

[Gordon]

just to add - rd/wr_auth are definitely still zero, and the nus library hasn't been touched.