I am using the CC2540 KeyFob with the HostTestRelease project configured for HCI control over UART with the GATT_DB_OFF_CHIP defined as TRUE. I am connecting with an iPhone 4S successfully, my advertisement data shows up, I can create the connection successfully, and answer FindByTypeRequests, ReadByTypeRequests, and ReadByGrpTypeRequests all successfull--this is all needed to inform the iOS device about the services/attributes.
Once the enumeration process of the services and attributes is complete, the iOS device issues a ReadRequest of the preferred connection parameters (handle 0x000B based on the attribute table that I have adopted from the TI Software Developer's Guide). The CC2540 responds, and a few moments later the link is terminated for reason 0x80 (supervisor timeout). I've read the other posts about this error message but I
Is this a problem that can be fixed? I know the connection parameters for the iOS device--simply matching them by calling SetParam() from my host-controller to the CC2540 doesn't seem to be working.
It is odd that the supervisor timeout seems to happen just after the iOS device has received the ReadResponse. A few times, maybe 5 out of 300, I've been able to see the iOS device register the fact that its ReadRequest has been answered by the CC2540. It's not consistent, and I think something fishy is happening.......
The preferred connection parameters are part of the BT 4.0 core spec (as part of the GAP profile), but unfortunately iOS central device do not make use of these values. You will need to send a peripheral connection parameter update request to the iPhone to change the parameters. More information on this can be found in this document from Apple:
https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf
Thank you very much for the response--does a mismatch in the parameters sound like the culprit? Is there a specific time during the connection that I should do a peripheral connection parameter update request? Just after link establishment, after discovery of services, etc.?
Hi Miles,
to save you from one headache (and introduce you to a few more in the process), check out these postings too.
http://e2e.ti.com/support/low_power_rf/f/538/t/204578.aspx
http://e2e.ti.com/support/low_power_rf/f/538/t/165206.aspx
Thanks for the help guys...it turns out that I was only going 2/3 of the way by providing 0x1800 and 0x1801 services, but not the device info service. Adding the device info service 0x180A made the iOS app very happy, and now it's working flawlessly.
That PDF really helped out a lot, thank you Willis1