ble_app_cscs Cycling Speed example advertises characteristics from the ble_app_gls Glucose example

[DCollins]

I have built and loaded the ble_app_cscs example, including the S140 Softdevice. I can connect with the Nordic_CSC peripheral, but rather than show Cycling speed characteristics the app instead shows blood Glucose characteristics. I've double checked that I'm loading the correct hex files. Loading is done via nRF Connect Programmer and JLink.

Bluetooth is connecting via iPhone with LightBlue and nRF Connect apps (both show the same characteristics).

The app is running an nRF52840 device within a Fanstel system and mounted on a custom board. There are connections to pins non-standard compared to the DK board, but the software apparently works, other than the small problem of appearing to be the wrong app. I have been able to change the manufacturer string and see it update to our company name.

I am inexperienced in Nordic devices, SDK and Bluetooth, although I've developed embedded ARM systems for many years. 

I have also tried to stuff the battery value (which exists in both the cscs and gls examples) to demonstrate I'm actually changing the example app, but battery values in the connected LightBlue app do not change.

[Einar Thorsrud]

Hi,

This must be an issue of caching in the iOS stack (which is done extensively). Just to be clear, the characteristics are not advertised, but some service UUIDs are. For both the DIS and battery service UUID are advertised, and in addition the GLS example advertises the glucose service UUID, and the CSCS example advertises the Cycling speed and cadence service.

As you refer to characteristics I wonder if you have looked at the service characteristics also? If so, those are populated after connecting and doing service discovery. If you subsequently change the example firmware on the same DK and do not connect this time, nRF Connect for iOS will still show the services and characteristics that were there before (this is the same device with the same Bluetooth address after all). And this will only be updated after connecting and doing a service discovery. Could that be what has happened?

You can also verify this using nRF Connect for Desktop Bluetooth (provided you have an additional DK or dongle), which do not do any caching like the iOS BT stack, so you can more easily see what is actually currently on the device.

[DCollins]

Yes, this was an iOS caching issue. 

After I posted the above, I moved over to an off-the-shelf nRF52840DK and had the same result with the Blinky example (I assume the UUID in the example is the same? I don't yet know where to change that). I also loaded two different BLE debug apps, which had the same problem.

After reading your post I rebooted the iOS entirely and suddenly I'm seeing the correct characteristics (I hope that's the right term) for Blinky. I then changed to our hardware and the CSCS based example, again rebooted iOS, and the correct CSCS characteristics showed up, as well as the value I stuffed into the battery value. I was able to change the battery value, recompile, and see the change. That was where I began the day yesterday trying to do.

Thank you for the help!