How to debug write command/request with invalid size

[Emmanuel Blot]

Hi,

I just spent several hours trying to figure out why, using a nRF52 dev kit w/ SDK13 + S132 on both central/client and peripheral/server side, sd_ble_gattc_read() was working like a charm while sd_ble_gattc_write() failed.

I added a debug trace to the BLE event manager top-level dispatch routine, i.e. softdevice_ble_evt_handler_set(ble_evt_dispatch) on the peripheral side to try to understand the problem with no success:

• sd_ble_gattc_write() returned no error with BLE_GATT_OP_WRITE_CMD and BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE event was successfully generated and/or,
• sd_ble_gattc_write() returned no error with BLE_GATT_OP_WRITE_REQ and BLE_GATTC_EVT_WRITE_RSP event was successfully generated with an zeroed length

while no BLE were even triggered on the peripheral side (where previous and next read requests were perfectly handled with the very same attribute and BLE connection).

I finally managed to locate my mistake: the write buffer on the central side was declared to be one byte longer than the actual attribute buffer maximum length on the peripheral side.

It seems that in this case, at least with no special configuration, no event is generated on the peripheral side to report the error, while the error on the central side is very hard to spot (written length == 0). I'm even more surprised not to received an event since the destination attribute was configured to request write permission.

From my understanding, it appears that the S132 SoftDevice discards a write request if the received buffer is longer than the declared attribute max length, but it does so silently.

Questions:

1. how to get a warning/notification/trace/whatever on such an event ("write request to long") on the server so that it is possible to debug the issue without guessing :-)
2. is it possible from a central role (client) to retrieve the maximum length of a peripheral attribute (server). I initially planned to use this feature for debug purpose, but as I failed to find an answer for this question, I skipped it. Maybe it is a limitation of the BLE protocol, but I failed to find an answer to this question
3. is there a better way to detect this error on the client side (for now, the only way I found is to test the write length from the BLE_GATTC_EVT_WRITE_RSP event)
4. is there some documentation about this issue (or guidance to avoid it). The NRF_ERROR_DATA_SIZE error code for sd_ble_gattc_write() is not triggered, so maybe it is reserved for local out-of-range buffers. AFAICT, there is no piece of information about this potential trap

Thanks.

[Petter Myhre]

1. I don't think there is any way to get an error on the server. Seems you have figured out how to detect the error on the client side.
2. It is not a procedure for it. For standard profiles, the length should be known. For your proprietary services your usually also know the length, if not, you should implement a way of finding it. You could for example have a couple of bytes inside the characteristic that contains the length. Then the client can read it. Or you could have a separate characteristic that the client can read. Or maybe use a descriptor, like Characteristic User Description descriptor.
3. As you figured out, check the gatt_status.
4. The SoftDevice doesn't know the length of the characteristic value you are trying to write to, so it can't produce an error code. It can only give an error after the response is received.

[Emmanuel Blot]

Thanks :-) - and thanks again for your help.

[perry_huang]

I also had a similar problem. Have you solved it？

[Emmanuel Blot]

Sorry, I do not remember.

I will not use SoftDevice anymore: there are now fully open source BT stack implementations for Nordic devices (Nimble, Zephyr, ...) so having to deal with closed source and undocumented magic is over :-)