Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

mutex updating characteristic value in application memory

When using BLE_GATTS_VLOC_USER to store multi-word characteristic values that are updated by application code, what is the recommended way to prevent a partially updated value being sent to a client?

Options I've considered include (in decreasing order of appeal):

  • Just disable all interrupts via PRIMASK, store the new value, and re-enable them. This is easy and robust, but would potentially delay SD high-priority interrupts by a couple microseconds.
  • Don't use BLE_GATTS_VLOC_USER.
  • Use read authentication so the application can schedule the update and read to avoid conflicts.

The first is the only one that's attractive. How timing sensitive is the soft device? Is a 10 us delay in processing SD interrupts likely to cause problems?

(My context is S130 2.0.1 with bare metal nRF51 programming, no SDK, but if there's a viable SDK-based solution I can probably adapt it.)

Parents
  • Hi Pabigot, 

    Sorry for late response. Wouldn't using sd_ble_gatts_value_set() is a better way of avoiding the value of the characteristic being accessed when partly updated ? 

  • Isn't the purpose of sd_ble_gatts_value_set()  primarily to update the a BLE_GATTS_VLOC_STACK value that's in the SD's RAM? It's also used when the length of a BLE_GATTS_VLOC_USER value is changed, but that might never happen.

    As I understand it BLE_GATTS_VLOC_USER exists so the values stored in user space can be exposed as characteristics. Several cases where that might be wanted:

    • values that are needed in the application in the same form they're exposed as characteristics don't have to be duplicated both user and SD RAM (here I'm thinking large structures containing sensor data)
    • values that may be rarely read but are frequently updated (e.g. clocks) will always provide the current value without making the application constantly tell the SD "it changed again; it changed again; ..."
    • the combination: in my case, a collected set of sensor data where pieces get updated at different times by application code that is decoupled from any communication infrastructure, so can't easily inform the soft device of exactly which pieces were changed.

    BLE_GATTS_VLOC_USER appears to have a lot of potential, but only if there's a way to ensure consistency when the soft device dips into the application memory to read the value.

  • it can also be used to update a value in USER RAM, it doesn't care where the value is, it just updates it. And it does it via a softdevice call which gives you the exact protection you're looking for. 

Reply Children
Related