Hi Simon, Yes, you are correct - the second callback indicates that the discovery operation is complete. You can determine that the procedure has successfully completed by checking the following:
* rc == 0 * service pointer is null If your callback only gets executed once, and the parameters are as defined above, that means the peer device does not support the service you are interested in. The reason for this somewhat awkward interface is that a device is allowed to support two different services with the same UUID. To resolve this ambiguity, the callback gets executed with special values indicating discovery is complete. By the way - I hadn't noticed that jira ticket you filed a few days ago. Sorry about that. I will close it with the above explanation shortly. On Mon, Jun 20, 2016 at 2:34 PM, Simon Ratner <si...@proxy.co> wrote: > Actually I think I just realised that might be what the mystery second > callback in https://issues.apache.org/jira/browse/MYNEWT-326 is. Is that > actually the "done" callback that just fails to set the error param > correctly? > > > > On Mon, Jun 20, 2016 at 2:32 PM, Simon Ratner <si...@proxy.co> wrote: > > > Hi devs, > > > > It appear that when I call ble_gattc_disc_svc_by_uuid with a service id > > that the device does not implement, I don't get any indication that is > the > > case. No callback, no error, just sits there holding up the connection > > resources. > > > > Same deal with ble_gattc_read_by_uuid. > > > > I would've expected a callback with an error value, or some other > > indication discovery was completed but the requested service/attribute > > wasn't found. > > >
