multiple services error code 0xf

[mac]

We are currently using SoftDevice 5.2.1 and was given the task to migrate to 6.2.1. I doing so, I placed 6.2.1 hex onto our device and turned it on. Yikes, many errors. Most notably are the 0xf errors coming from sd_ble_uuid_vs_add(). We have 3 custom services with their associated characteristics. The current code has 3 distinct functions that are called to initialize each service and characteristics. The functions do the following sd_ble_uuid_vs_add() sd_ble_gatts_service_add() and finally sd_ble_gatts_characteristic_add(). All works well in 5.2.1 but 6.2.1 works for the first service and characteristics, but the second function call for the seconds service and characteristics dies at sd_ble_uuid_vs_add() with error code 0xf. I see from the release notes that sd_ble_uuid_vs_add() has been changed to not allow for duplicate calls for the same UUID. That being said, does that mean I am going to have to change the code to add all services and characteristics in the same function that has the initial call to sd_ble_uuid_vs_add() ?

[Ulrich Myhre]

Hi,

When you switch between major versions of the SoftDevice, you must at the very least recompile against the new headers in the new release. The migration document included in the release should outline the necessary changes needed for the upgrade.

Without doing this, your SVC number mappings might be wrong, and you end up calling different APIs than you think you are (with very wrong variables).

[RK]

If you're using the same 'base' UUID for all your services (which is what I do because it makes life a whole lot easier) than you have a couple of options. I keep a global handle to the registered UUID which starts at zero at runtime, and have a function to return the registered handle. When I call the function, if the handle is still zero, I do the registration cache and return it, else I just return the one I cached.

That means you can do your service instantiation in any order, instead of each one doing the uuid_vs_add(), you just call your one-true function and get the handle, whichever is the first will do the registration, the rest will just get the cached value.

That API call is slightly annoying, since it knows the custom UUID was already registered, it must know which handle it was registered under and it could just return it thus meaning you don't really have to care if you register the same one multiple times, you get the same handle. I could live with it returning the 'already registered' return code, but it would be nice if it also put the handle into the variable anyway so I could check for that condition and keep going instead of having to write that one global function.

[Ulrich Myhre]

The uuid_vs_add() call will return success and populate the type from s110 7.0 and beyond (and already be in s120 2.x.x and s130 1.x.x). Seems this was not put in the release notes.

[RK]

Oh - that's not what the documentation says either, it still says it will return NRF_ERROR_FORBIDDEN if the UUID has already been added to the table. (That's the sdk 8 docs I just checked)

[Ulrich Myhre]

Yeah, some information got lost there I think. I will raise this internally so the documentation is fixed. Someone reported this annoyance late 2013, and we agreed and fixed it back then. Looking at the source now, it should populate the handle and return success now.