GATT Write Event data restricted to only 1 byte

[Maz Shar]

The following seems to suggest each write event can only contain 1 byte of data at a time.

/**@brief Event structure for @ref BLE_GATTS_EVT_WRITE. */

typedef struct
{
  uint16_t                    handle;             /**< Attribute Handle. */
  uint8_t                     op;                 /**< Type of write operation, see @ref BLE_GATTS_OPS. */
  ble_gatts_attr_context_t    context;            /**< Attribute Context. */
  uint16_t                    offset;             /**< Offset for the write operation. */
  uint16_t                    len;                /**< Length of the received data. */
  uint8_t                     data[1];            /**< Received data, variable length. */
} ble_gatts_evt_write_t;

I would like to have an array of bytes which I loop over and can parse. Considering that when we add characteristics and update them, they are added as an array of bytes, it must be possible to write more than one byte to them.

Could I have some clarification on this?

If this is the case, why have the need for a 16-bit length, if we know it will always be 1?

I know the following will compile, however, the explicit size 1 for data must cause memory issues at some point.

	uint8_t * NewCharData = pWriteEvent->data;

If this is not the case (and you can write more than 1 byte at a time), could you explain the purpose of explicitly stating data[1]?

I'm using SDK 9.0.0 with latest softdevice S110 version and an nrf51822.

[RK]

It's a pretty standard C idiom. You can see there's a length in there so you know there is more than one byte of data, it just means data is a pointer to uint8_t with at least one byte in it, you can just use it as a pointer to uint8_t with the cast, as you did, and read up to length bytes, the actual data pointed to will contain all the 'len' bytes.

[Pål Håland]

Also explained in this answer: devzone.nordicsemi.com/.../

[Maz Shar]

"You can see there's a length in there so you know there is more than one byte of data."

The fact there is a length doesn't mean we know there is more than one byte of data. That just tells us how far to read which can still be the wrong place, right?

"It just means data is a pointer to uint8_t with at least one byte in it."

This does not seem to be the case with regards to safe memory allocation. I've looked at the memory through the debugger and saw that there is 1 byte allocated in the memory directly for data in the ble_gatts_evt_write_t structure and not a 4-byte pointer which points to a value...

[Maz Shar]

I'm still interested in a response to my above comment. Thanks!

[RK]

The debugger just shows you what it thinks it knows which is one byte, the actual data pointed to is safely allocated to be the correct length and can be read.

[Maz Shar]

I have discovered this is only "safe" because an extra 23 bytes is allocated for the event buffer when initialising the soft device.

See BLE_STACK_EVT_MSG_BUF_SIZE in ble_stack_handler_types.h which is allocated the size of a ble event + GATT_MTU_SIZE_DEFAULT (23 bytes).

So, the data property serves merely as a starting address. The write event secretly has an extra 23 bytes allocated to "account for" 20 bytes of data (removing headers).

This is hacky and not what your answer informed me about at all.

Would it not work to assign that GATT_MTU_SIZE_DEFAULT to data property itself i.e. data[GATT_MTU_SIZE_DEFAULT - GATT_HEADERS]? where GATT_HEADERS = 3