mutex updating characteristic value in application memory

[pabigot]

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.)

[Hung Bui]

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 ? 

[pabigot]

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.

[RK]

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. 

[pabigot]

Ah.  OK, I can see that.  So it gives me the protection, but not the features I was actually looking for (eliminated duplicate storage and overhead updating fast-changing values).  Disappointing.

[ovrebekk]

Hi Peter

You might be able to use timeslots to do what you want. 

Request a timeslot long enough to do your data update procedure, and you will know that the SoftDevice is not doing anything for the duration of the timeslot. 

I haven't tested it myself though, just a thought ;)

Best regards
Torbjørn