How to support BLE_GATTS_VLOC_USER ?

[danielkelly]

I have found the bellowing code which was in s130/ble_gatts_struct_seriallization.c of nRF51_SDK_10.0.0 : ( ble_gatts_attr_md_enc)

---

/* serializer does not support attributes on stack */

if (p_attr_md->vloc != BLE_GATTS_VLOC_STACK)    {

   err_code = NRF_ERROR_INVALID_PARAM;
}

---

Is that to say the s130 softdevice only support BLE_GATTS_VLOC_STACK, not the BLE_GATTS_VLOC_USER ?

Further more how to support BLE_GATTS_VLOC_USER?

What is the meaning "Attribute Value is located in user memory. This requires the user to maintain a valid buffer through the lifetime of the attribute, since the stack will read and write directly to the memory using the pointer provided in the APIs." ??

[Vidar Berg]

BLE_GATTS_VLOC_USER is not supported with the serialization examples, but are you sure you need it? The GATT server attribute table is now configurable in s130 v.1.0.0 so you can increase it to meet your requirements, see ble_enable_params.gatts_enable_params.attr_tab_size = BLE_GATTS_ATTR_TAB_SIZE_DEFAULT; in ble_stack_init().

What is the meaning "Attribute Value is located in user memory. This requires the user to maintain a valid buffer through the lifetime of the attribute, since the stack will read and write directly to the memory using the pointer provided in the APIs." ??

It basically means that you've to keep this data in RAM in your application region, and that it must be statically allocated.

[Vidar Berg]

BLE_GATTS_VLOC_USER is not supported, which means that the GATT values need to be stored in the softdevice's RAM space (BLE_GATTS_VLOC_STACK), but as I mentioned in initial reply, this should not be a problem with the newer softdevices as you can a increase the default RAM allocation for the stack if needed.

However, the /* serializer does not support attributes on stack */" comment is a bit confusing. You can see from the code that BLE_GATTS_VLOC_STACK is in fact the only supported option, but since it says "on stack" I'm wondering if it possibly could be referring to the call stack, although it doesn't make much sense. I will report this as a bug internally.