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.

RTOS/SIMPLELINK-CC2640R2-SDK: Lots of RETRY Packet in a BLE connection

Part Number: SIMPLELINK-CC2640R2-SDK
Other Parts Discussed in Thread: CC2640R2F

Tool/software: TI-RTOS

Hello,

My project is based on simple_peripheral_oad_onchip project and running on custom board.
My SDK version is 1_35_00_33.
CC2640R2F is used in the custom board.

Custom board is nearly same with TI Reference design and there is a button in the custom board.
The custom board operates on a coin cell battery.

The button has two use cases which are waking up the board from shutdown state and starting sending of the connectable packet.

After the loading the code into the custom board, the custom board will be in shutdown state.

Here is the brief story of my problem;
1) I pressed the button to wake-up the custom board.
2) After the pressing the button, the board will be awake and the SimpleBLEPeripheral_taskFxn task will run. At the same time, the custom board will send connectable beacon packets to connect our mobile application to exchange data.
3) After the communication between the mobile application and the custom board ends, The custom board will send non-connectable beacon message at a fixed interval. 
(I checked that there is no problem sending non-connectable beacon messages)
4) After a while (like 10 days), I pressed to button to make the custom board connectable.
5) The custom board started to send connectable beacon message and I verified by using the packet sniffer.
6) When I attempt to connect to the tag by using the mobile application, the connection takes so much time. Because of the lots of RETRY packet.
According to packet sniffer logs, Master device (mobile phone) tried to send a request and it seemed that slave device did not respond to the request.
I attached the packet sniffer log to check what's going on. 

Here is the list of what I did to address the problem;
1) I checked the voltage on batteries and it seemed normal. 
2) I checked RSSI value and rate of CRC and FEC errors. It seemed normal.
3) I tried to recreate the problem in another custom board, I did not run into the problem.

I think the problem occurs when the tag operates so much time.
I woke up the custom board by pressing the button. I sent the configuration to the custom board by using mobile application. After 20 hours, I pressed the button to reconnect to tag. The connection was successful.

I measured the elapsed time to connect to the custom board and sending the configuration;
The custom board that has difficulties to connect-> It took nearly 26 seconds to send configuration.
The custom board that has not difficulties to connect -> It took nearly 4 seconds to send configuration.

Any help would be appreciated.
Have a nice day.
Best Regards.

ble_log.psd

  • Hi,

    Can you migrate to a newer version of the SDK (2.20 is the latest, 1.35 is over a year and a half old) and see if you continue to see the issues? We have made a large number of improvements to the SDK and the functionality since.
  • Oops, didn't mean to click thinks resolved. Please do try it on 2.20 though.
  • Hi Evan,

    I will check the problem in the new SDK.
    However, I need to address the problem for SDK 1.35 and I need to upgrade the firmware.
    Do you have any suggestion that i should look for in the first place ?

    Thank you
    Best regards

  • Hi Evan,

    I forget to mention.
    We are using SDK 1.35 since the release date. We did not have any problem with the SDK until now.
    I encountered with this problem on some of the devices. Some devices operate properly.

    I found another problem.
    When i connect to tag, the connection will down immediately. Here is the log Btool

    --------------------------------------------------------------------
    [40] : <Tx> - 04:13:33.777
    -Type : 0x01 (Command)
    -OpCode : 0xFE09 (GAP_EstablishLinkRequest)
    -Data Length : 0x09 (9) byte(s)
    HighDutyCycle : 0x00 (0) (Disable)
    WhiteList : 0x00 (0) (Disable)
    AddrTypePeer : 0x00 (0) (Public)
    PeerAddr : 40:ED:98:E0:05:6A
    Dump(Tx):
    0000:01 09 FE 09 00 00 00 6A 05 E0 98 ED 40 .......j....@
    --------------------------------------------------------------------
    [41] : <Rx> - 04:13:33.807
    -Type : 0x04 (Event)
    -EventCode : 0x00FF (HCI_LE_ExtEvent)
    -Data Length : 0x06 (6) bytes(s)
    Event : 0x067F (1663) (GAP_HCI_ExtentionCommandStatus)
    Status : 0x00 (0) (Success)
    OpCode : 0xFE09 (GAP_EstablishLinkRequest)
    DataLength : 0x00 (0)
    Dump(Rx):
    0000:04 FF 06 7F 06 00 09 FE 00 .........
    --------------------------------------------------------------------
    [42] : <Info> - 04:13:34.529
    Device Connected
    Handle = 0x0000
    Addr Type = 0x00 (Public)
    BDAddr = 40:ED:98:E0:05:6A
    --------------------------------------------------------------------
    [43] : <Rx> - 04:13:34.512
    -Type : 0x04 (Event)
    -EventCode : 0x00FF (HCI_LE_ExtEvent)
    -Data Length : 0x14 (20) bytes(s)
    Event : 0x0605 (1541) (GAP_EstablishLink)
    Status : 0x00 (0) (Success)
    DevAddrType : 0x00 (0) (Public)
    DevAddr : 40:ED:98:E0:05:6A
    ConnHandle : 0x0000 (0)
    ConnRole : 0x08 (8) (Central)
    ConnInterval : 0x0050 (80)
    ConnLatency : 0x0000 (0)
    ConnTimeout : 0x07D0 (2000)
    ClockAccuracy : 0x00 (0)
    Dump(Rx):
    0000:04 FF 14 05 06 00 00 6A 05 E0 98 ED 40 00 00 08 .......j....@...
    0010:50 00 00 00 D0 07 00 P......
    --------------------------------------------------------------------
    [44] : <Info> - 04:13:35.057
    Device Disconnected
    Handle = 0x0000
    Addr Type = 0x00 (Public)
    BDAddr = 40:ED:98:E0:05:6A
    --------------------------------------------------------------------
    [45] : <Rx> - 04:13:35.053
    -Type : 0x04 (Event)
    -EventCode : 0x00FF (HCI_LE_ExtEvent)
    -Data Length : 0x06 (6) bytes(s)
    Event : 0x0606 (1542) (GAP_TerminateLink)
    Status : 0x00 (0) (Success)
    ConnHandle : 0x0000 (0)
    Reason : 0x3E (62) (Failed To Establish)
    Dump(Rx):
    0000:04 FF 06 06 06 00 00 00 3E ........>
    --------------------------------------------------------------------

      

    Update:
    In CCFG section, DC/DC is enabled and I am disabling the DC/ from application side by writing AON_SYSCTL_BASE + AON_SYSCTL_O_PWRCTL register at top of the main function.

    #define APP_DISABLE_DC_TO_DC                    0x01
    HWREG(AON_SYSCTL_BASE + AON_SYSCTL_O_PWRCTL) = APP_DISABLE_DC_TO_DC;

    Is it safe method to disable the DC/DC?



  • Erdem,

    Is the TI Device in this case the master? there are a number of packet retrys in this log to where it looks like the slave is not responding. Have you seen this behaviour in debug mode? Does the device lock up in any way during this connection?

    The termination reason code given is 0x13 which indicates a timeout. I'm concerned your device is locked up, either receives some sort of exception, icall_abort or runs out of heap. Could be any of them and further debugging in the code to see what's happening during the connection. This could be done by debugging the heap memory and using HAL asserts. Look in our Stack Users Guide for info on how to do that.

    I also still recommend seeing if you see the issue in 2.20 as 1.35 is rather out dated and there have been a number of bug fixes to the stack since.
  • I'm going to close this post due to inactivity. To reopen this thread, just post a follow up question. Otherwise, after 30-days of inactivity from this post, this thread will lock.