Part Number: CC2340R5
Other Parts Discussed in Thread: SYSCONFIG
Good day.
My team and I are writing some firmware for the CC23, acting as a BLE Peripheral.
We noticed that, with the default connection parameters, iOS (acting as Central) fails to connect.
Here are our observations:
- iOS does not report a 'connected' state back to our application
- Our embedded side shows that a connection has been established
Using a Bluetooth HCI Logging profile on and iPhone, and reading the HCI log via PacketLogger (mac software), we noticed the following:
- The mobile tries to negotiate connection parameters using 50 (62.5ms) for both min and max connection interval
- The embedded side responds with an (acceptance) reply containing minConnectionInterval 12 (15ms) and maxConnectionInterval 24 (30ms).
- (There is no overlap between the two intervals)
- Here communication just stops, no disconnect, nothing
- The implication is that: this is not a pairing issue, but a connection issue.
As an experiment, we tried using GAP_UpdateLinkParamReq with the lenient values of 50 for min & max connection interval multipliers, 0 connection latency, and 500 ms connection timeout.
We noticed the following:
- The mobile tries to negotiate connection parameters using 50 (62.5ms) for both min and max connection interval
- The embedded side responds with a minConnectionInterval of 50 (62.5ms) and a maxConnectionInterval of 62 (77.5ms)
- The mobile side sends a connection update complete message, agreeing on a connection interval of 50 (62.ms)
- The current default connection parameters on the embedded side are incompatible with iOS.
- Even after connecting, we can not trigger a pairing attempt; There are no iOS APIs to create a pairing relationship. Instead, pairing is triggered when a characteristic interaction returns insufficient authentication / authorization.
We have the following questions for you at TI:
- Why does communication between the phone and chip just stop? We would expect it to fail or continue with the current connection parameters; (Who is waiting on who?)
- If this is a bug of iOS itself, we can not do anything about it, only report it to be solved by Apple in the future
- When there is no overlap between support connection parameters, should the embedded side respond with a HCI_LE_Remote_Connection_Parameter_Request_Negative_Reply instead?
- We noticed that the supervision timeout did not update to the requested value (500).
- We couldn't find the 12/24 default parameters anywhere in the code, does TI use default parameters that are incompatible with iOS? Where are they set?
- We found ti_ble_config.h, but it mentions intervals of 400 min, 800 max, 0 latancy, and 600 timeout.
- We also found gap_initator.h, but that mentions 80, 80, 0, and 2000. I also suspect that file is not used in our use case as a Peripheral.
- What should the correct parameters be?
We found the GapInit_setPhyParam() function, so perhaps we should start with adding that somewhere in our initiation code?
Something like this: (replacing the values with sensible defaults)

