• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 566 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2F: HostTest firmware seeing a lot of SUPERVISION_TIMEOUT with Peripheral role supporting multiple connections

Arun PM
Intellectual 630 points
Part Number: CC2640R2F

Hi,

We use Hosttest Firmware in one of our product supporting multiple connections(now supports 3 peers and planning to increase to 5) in peripheral mode with data(10-20KB) exchange to iOS peers using Notification.
We are facing SUPERVISION_TIMEOUT when we start seeing BLE_PENDING error continuously from firmware.
And this peer when trying to connect back after such a disconnection; again it keep on connecting and disconnecting with SUPERVISION_TIMEOUT on subsequent attempts.

If we leave the connection idle without any data exchange or small data exchange; it is stable.

Any suggestion or guidance is deeply appreciated.


Custom hardware is using USE_RCOSC configuration and connection parameters are as below:
 
Advertisement Interval : 23.125ms
Connection Establishment Interval (min/max) : 60ms & 80ms
Connection Establishment Latency : 0
Supervision Timeout : 5 sec
Sleep Clock Accuracy : 500
Connection Pause Peripheral : 6

  • 0
    TI__Mastermind 33460 points

    Hi Arun,

    Thanks for the information. It would be helpful if you can further clarify this statement:

    "We are facing SUPERVISION_TIMEOUT when we start seeing BLE_PENDING error continuously from firmware"

    Who encounters the supervision timeout? Is it the iOS device, is it the host_test device? Where is BLE_PENDING returned from? Is it the call to GATTServApp_ProcessCharCfg()?

    Can you run the following tests on the device? 

     1. Enable HEAPMGR_METRICS

     2. Reproduce the issue and trap

     3. Observe/report heap metric variables that are listed here: http://dev.ti.com/tirex/#/?link=Software%2FSimpleLink%20CC2640R2%20SDK%2FDocuments%2FBLE-Stack%2FBLE-Stack%20Debugging%20Guide under the "Debugging common Heap issues" section

      

  • 0 in reply to Sean2
    TI__Mastermind 33460 points
    One more potential path to having the notification return blePending is if there are currently any GATT procedures in progress with this client. If so they must complete before sending more notifications. Please attach a sniffer capture showing the transactions with all connected devices.
  • 0 in reply to Sean2
    Intellectual 630 points

    Hi

    Thanks for helping us.

    Regarding "We are facing SUPERVISION_TIMEOUT when we start seeing BLE_PENDING error continuously from firmware":
    iOS App is the central and Hosttest Firmware(FW) (GATT_DB_OFF_CHIP) is the peripheral. HostTest Firmware is managed by a custom Linux Application(BTClient) which resembles BTool implementation in a usecase driven model.
    Upon data, BTClient uses GATT_Notify routine to send that data to Hosttest FW which in turn notifies the App. BTClient waits till response of GATT_Notify() is received before calling it again with next data.
    As the data is large (more than 20KB), BTClient keep on using GATT_Notify unless the response is success.
    When the setup is in long run; after around 20 minutes from very first call of GATT_Notify(); BLE_PENDING error starts to appear in GATT_Notify() response; for every next GATT_Notify() call.
    And it continues for about ~10min and then the connection drops with LinkTermination event with reason SUPERVISION_TIMEOUT at BTClient or HostTest FW.

    Will update you with the suggested Test case results shortly.