Closed adfernandes closed 8 years ago
ARM Internal Ref: IOTSFW-1027
I close this, I'm not able to reproduce this issue.
I didn't encounter any issue during discovery of services with multiple 128 bits UUID (characteristic and/or service) published on Android or iOS.
So this bug took a while to track down.
When publishing a service with CoreBluetooth, service discovery would always terminate early after discovering only one long-UUID service.
iOS publishes several services from the OS layer, it adds the application-defined
CBMutableServices
to the GATT table as needed.My Android device (Nexus 4, OS 5.1.1), my Mac (OS 10.10.4), and my Linux box (Bluez 5.32) had no problems with service discovery.
When I hunkered down in the debugging (thanks to Segger's RTT!) I found that the
sd_ble_gattc_characteristics_discover
call at line 142 ofnRF51ServiceDiscovery::progressCharacteristicDiscovery(void)
was returningNRF_ERROR_BUSY
.So this shouldn't be a big deal, right? Just wait a few milliseconds and try again!
Wrong. The current class logic makes that... well, not a trivial fix. :frowning:
The
progressCharacteristicDiscovery
member is called from the BLE event loop. So you cannot just delay for time and attempt to re-schedule thesd_ble_gattc_characteristics_discover
. You have to return from the event loop before you re-schedule the call.The problem is, if you don't terminate service discovery, the event loop is never called again, and/or the class enters an inconsistent state.
So, I'm thinking that the
ServiceDiscovery
class needs to have a property that gets set if the client was busy... and then you need to poll the property. Or maybe set this up in some sort of event handler?It's tricky; I'm not sure how small the API change needs to be to be able to accommodate this.
But anyway, the behaviour is repeatable if you attempt discovering all services and characteristics of an advertising iPhone. It doesn't matter what services are being published.
Thankfully, if you add a long-UUID filter on
launchDiscoveredServices
, the calls work just fine and the stack allways reportsNRF_SUCCESS
.But this is a pretty serious limitation for service discovery. :cry: