I've been working through the tutorials on BLE Services & Characteristics. That's all gone fine for me. Now I'm adjusting the sample code to use different UUIDs for my own custom service and characteristics.
I'll flash a new firmware where I've changed #define BLE_UUID_OUR_BASE_UUID from the sample to my own base UUID. I'll get a successful flash confirmation. Then I'll run LightBlue Explorer or nRF MCP on my iPhone or Android device and interrogate my peripheral.
Most of the time, I don't see the BASE_UUID updated when I interrogate the device. I've been trying workarounds like killing the iPhone app, turning off bluetooth on the iPhone, then turning it back on and restarting. I've tried switching between apps. I've tried switching between phones. I've even started unplugging the NRF51-Dongle from USB in order to hard-cycle power. Occasionally its updated, but I haven't been able to figure out a pattern of when it will work and when it doesn't.
I've switched to progressively more 'hardcore' flashing techniques. I started with
nrfjprog --program ... --sectorerase
Then moved to reflashing the S130 soft device first, now I'm calling mergehex and chiperase every time I flash:
nrfjprog -f nrf51 --program .../combined.hex --chiperase
I still haven't found the 'right pattern' where I can consistently get the BASE_UUID to change after compile/flash.
I've wondered if it's a ble caching problem on the ble stacks of the phones themselves, so I've installed a second nrf51-dongle running nrf sniffer and I can validate that the GATT packets are showing the stale UUIDs as well, so I don't think that's the cause.
Has anyone else struggled with this problem? If so is there some change to my workflow I need to make to tell the nrf51-dongle 'I really really mean to make a change this time' :-)
- jcb