This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Handling BLE_EVT_USER_MEM_RELEASE

As a central, I am writing to a variable length characteristic, advertised by a service of my peripheral. In this case, I am sending 80 bytes of 0x01 as a test

    uint8_t testData[80];
    size_t len = sizeof(testData);
    memset(&testData, 0x01, len);
    NSData *valData = [NSData dataWithBytes:&testData length:len];
    [self.peripheral writeValue:valData forCharacteristic:self.txCharacteristic type:CBCharacteristicWriteWithResponse];

image description

From a peripheral standpoint, I am relying on BLE_EVT_USER_MEM_REQUEST and replying with a statically allocated struct of type ble_user_mem_block_t. This block has enough memory to handle the write from the central. I then handle BLE_EVT_USER_MEM_RELEASE and attempt to dump the blocks p_mem buffer via NRF_LOG_HEXDUMP_DEBUG. This is where I'm stuck. The problem is, the contents of p_mem do not match what i was expecting, which is 80 bytes, set as 0x01. For example,

image description

In this post, it mentions a format of [HandleID 2 bytes] [Offset 2 bytes] [Length 2 bytes] [Data], but even then, the data isn't making sense to me, leading me to believe I've either misinterpreted the data, or I am logging in the wrong place. Can anyone steer me in the correct direction. My short term goal is to log the data that was written to this particular characteristic.

Here are the wireshark logs for reference.

Thanks!

Device: nRF52832 SDK: 13 Soft Device: S132

  • For anyone with a similar problem, I was able to solve my issue with the use of sd_ble_gatts_value_get inside BLE_EVT_USER_MEM_RELEASE. Since I only have 1 characteristic in my long write, I use the first 2 bytes from my ble_user_mem_block_t to determine what handle the write is for, based on this format. With that said, the hexdump in the screenshot above from ble_user_mem_block_t is still a mystery to me, I understand where 14 comes from(handle) but I have no idea what 12 refers to as it's not in the wireshark capture. I will tackle that another day.

Related