search

ARMmbed / ble-nrf51822

Nordic stack and drivers for the mbed BLE_API
Other
46 stars 51 forks source link

nRF51822ServiceDiscovery fails on iPhone5 with NRF_ERROR_BUSY #27

Closed adfernandes closed 8 years ago

adfernandes commented 9 years ago

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 of nRF51ServiceDiscovery::progressCharacteristicDiscovery(void) was returning NRF_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 the sd_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 reports NRF_SUCCESS.

But this is a pretty serious limitation for service discovery. :cry:

rainierwolfcastle commented 8 years ago

ARM Internal Ref: IOTSFW-1027

pan- commented 8 years ago

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.