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: Connection timeout with OAD Split Image

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

Tool/software: TI-RTOS

Hi Team,

I have installed "SimpleLink CC2640R2 SDK 2.20.00.49" and "CCS_8.1.0" as the development environment. We have a customized application(broadcaster)  built using this SDK with stack library method and was working as per our needs. In order to perform On-chip OAD for our application, we started migrating to split-image method as per the guidelines and have taken "simple_peripheral_oad_onchip" example as the reference. In this phase, the following functionalities are getting merged (Peripheral, split-image and OAD) from the example "simple_peripheral_oad_onchip" to our application.

The stack and application images are build successfully for package "CC2640R2DK_5XD". BIM and persistent application are taken from "simple_peripheral_oad_onchip".

With the above mentioned setup, the device advertises but the connection procedure is not getting completed. Timeout happens while "Discovering Services".

During connection, the following error is seen: [logs]

Connected to "Device Mac Address"

Error 129 (0x81): GATT INTERNAL ERROR

Error 22 (0x16): GATT CONN TERMINATE LOCAL HOST

Disconnected

Need your inputs on which parameters to be verified/memory issues(heap/stack requirements) that may cause this problem.

Thanks,

Arul Christopher

  • Hi Arul,

    Are you using the CC2640R2F Launchpad or a custom CC2640R2F Board? Did you set the correct RF Front End and Bias configuration symbol at the board file?

    * Define only one symbol:
    * CC2650EM_7ID - Differential RF and internal biasing
    (default for CC2640R2 LaunchPad)
    * CC2650EM_5XD – Differential RF and external biasing
    * CC2650EM_4XS – Single-ended RF on RF-P and external biasing
    * CC2640R2DK_CXS - WCSP: Single-ended RF on RF-N and external biasing
    * (Note that the WCSP is only tested and characterized for
    * single ended configuration, and it has a WCSP-specific
    * PA table)

    The Simple Peripheral On-Chip OAD Example Program works, try it. Converting it to Broadcaster Mode should be no problem.

    -kel
  • Hi,

    Thanks for the quick reply.

    I have been using a custom CC2640R2F board and have set the symbol "CC2650EM_5XD" for differential RF and external biasing. Even with this, I am facing the above said issue.

    As you said, we have taken Simple Peripheral On-Chip OAD example as the reference while building the application.

    Thanks,
    Arul Christopher
  • Hi Arul,

    Does the original Simple Peripheral On-Chip OAD Example Program work at your Custom Board? To make it work just do not initialize any pins and set your symbol CC2650EM_5XD.

    -kel
  • Hi. Is there any update here? If not, I will be closing the thread due to inactivity.
  • Hi,

    The OAD On-chip application with split image configuration works by setting the symbol CC2650EM_5XD in our custom board.

    But we have a customized application built following the same pre-defines and options present in the example application. In this case, the "Service discovery" fails.

    Is there any requirement for heap size to have minimum available size?
    Because in our customized application the heapsize comes around 5000 bytes(heapend - heapstart) whereas in example application it is around 9000 bytes.

    The Error log is below:

    Discovering Services..
    gatt.discoverServices()
    [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
    [Callback] Services discovered with status: 129
    Error 129 (0x81): GATT INTERNAL ERROR
    [Callback] Connection state changed with status: 22 and new state: DISCONNECTED (0)

  • It is difficult to comment on what this error is without a sniffer capture. If you had the capture, you would be able to see where in the discovery it is failing.

    Is the device non-responsive when this occurs or does it continue advertising / functioning as expected? You may want to replicate this with the debugger than pause once the error occurs to see what is happening.

    There is no specific heap size that is quoted however it is possible that you are running out of heap. Please verify this by checking the heap size: dev.ti.com/.../ble-index.html
  • Hi,

    Attaching the sniffer capture.

    Here in this capture, no response is received for "ATT_Read_By_Group_Type_Req".

    Finally master issues a "LL_Terminate_Ind".

    The device stops advertising after this and functions only after a hard reset.

    And at the BLE peripheral end, following behaviour is seen by debugging:

    1. Gap state changes to "GAPROLE_CONNECTED" on the "Connect" request. Immediately following this state changes to "GAPROLE_WAITING". No crash is seen in the debugger. But after this, connection establishment does not complete and device is not advertising.

    Also the memory usage analysis is done following the link that is provided in the above comments:

    1. Ti Simplelink SDK: simplelink_cc2640r2_sdk_2_30_00_28
    2. xdctools: xdctools_3_50_08_24_core
    3. TI Compiler: 18.1.3.LTS

    Heap Global variable values (through debugger):

    heapmgrBlkMax (The maximum amount of simultaneous allocated blocks) 55
    heapmgrBlkCnt (The current amount of allocated blocks) 54
    heapmgrBlkFree (The current amount of free blocks) 15
    heapmgrMemUB (The furthest memory location of an allocated block, measured as an offset from the start of the heap) 2940
    heapmgrMemAlo (The current total memory allocated in bytes) 2560
    heapmgrMemMax (The maximum amount of simultaneous allocated memory in blocks (this value must not exceed the size of the heap) 2860
    heapmgrMemFail (The amount of memory allocation failure (instances where ICall_malloc() has returned NULL)) 0

     

    Heap Size: 5932 bytes (heapEnd: 20003b98  heapStart: 2000246c)

    Inference: heapmgrMemMax < Heap Size, this indicates there are no issues with heap

     

    Task Stack and System stack:

      Priority Stack size Stack peak
    Idle Task 0 512 280
    BleTask(Application) 2 640 372
    GapRoleTask 3 480 420
    Icall_TaskEntry 5 1000 536
    System stack   1024 444

     

    Thanks,

    Arul Christopher

  • Hi. Can you attach the complete capture (the file) instead of a screenshot?
  • Ok thanks. Unfortunately, the sniffer doesn't tell us much. The heap does look fine.

    I think the next step is to see how the GAPRole is getting into GAPROLE_WAITING. I would try logging each event and status when gapRole_processGAPMsg() is called.
  • Hi,

    The reason is compiler.opt file was not used during the compilation of application and driver files.

    Thanks for the support

    Thanks,
    Arul Christopher