• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 51 subscribers
  • Views 416 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.

CC2642R: The application did not get GAP_LINK_ESTABLISHED_EVENT after Bluetooth connection.

Shepherd Qu
Prodigy 110 points
Part Number: CC2642R
Device: LaunchPad，simplelink_cc13xx_cc26xx_sdk_5_40_00_40
Phone: HUAWEI Mate 50, HarmonyOS 3.0.0
1. This phone is connected to the device, and the application did not get the GAP_LINK_ESTABLISHED_EVENT event.
2. This phone was able to imitate a pairing request, but the paring failed and terminated, and the application did not get the GAP_LINK_TERMINATED_EVENT event.
3. The UART works normal before connection, cannot out logs after the connection.
4. The program runs normally and does not crash. (Debugging mode)
5. This issue will reproduce after reset.
6. It will not reproduce that using another phone to connect to this device.
7. It will not reproduce that using this phone to connect to another device.
Please check the sniffer log.
  • 0
    TI__Mastermind 42100 points

    Hi Shepherd,

    Can you specify which application is being used on the CC2642 device? Are you using simple_peripheral? Are you observing this on a modified example? If so, then can you try to reproduce this behavior on a unmodified example?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 110 points

    Yes, it is simple_peripheral, this issue cannot be reproduced now, but it's real, because we have many products in the market that are advertising stops. this is the only time it's been reproduced in our lab. 

  • 0 in reply to Shepherd Qu
    TI__Mastermind 42100 points

    Hi Shepherd,

    Got it. Understood. Looking through the logs, I have filtered by the HUAWEI phone and saw the following packets:

    Is the E0:F4:42:F5:85:28, the simple_peripheral device? Has any pattern been observed with the devices that exhibit this behavior? Does the behavior tend to occur in environments with heavy BLE traffic? Is the device in a connection when the behavior occurs? It is possible that this behavior has been addressed in a newer SDK release. If a way to reproduce the behavior is found, then I would highly recommend seeing if updating to the latest SDK resolves the behavior.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 110 points

    Hi Jan, I'm sorry I didn't make my device clear, the simle_peripheral device is 80:6F:B0:EE:AA:96, device name is HOZ4887F4F7A0EE.

  • 0 in reply to Shepherd Qu
    TI__Mastermind 42100 points

    Hi Shepherd,

    Thank you for clarifying. No worries!

    Looking through the packets there seems to be some issues. The central device seems to send a message that is labelled SMP Unknown by the Ellisys software, which I am unsure what it is. I am also seeing that the simple_peripheral device responds with an empty packet to the connection parameter request from the central device. Was the sniffer log recording an unmodified simple_peripheral or your custom application based on simple_peripheral? Is the option to send a connection parameter request enabled in your application?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 110 points

    Hi Jan, 

    Is a modified application based on simple_peripheral.

    1. The connection parameters are set as follow.

    2. Only 1M PHY is allowed and masked code for PHY switching.

    // Only 1M PHY is allowed for transmitter and receiver PHY to be used for all subsequent connections.
    (void)HCI_LE_SetDefaultPhyCmd(HCI_PHY_USE_PHY_PARAM, HCI_PHY_1_MBPS, HCI_PHY_1_MBPS);

    3. The code for the connList variable in the application has not changed.

    4. The code in the GAP_UPDATE_LINK_PARAM_REQ_EVENT and GAP_LINK_PARAM_UPDATE_EVENT events in the application is unchanged.

  • 0 in reply to Shepherd Qu
    TI__Mastermind 42100 points

    Hi Shepherd,

    Got it. Thank you for the details! Can you try seeing if the behavior can be seen in an unmodified example? This will help us narrow down what modification may be causing the behavior.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 110 points

    Hi Jan, 

    It has not been reproduced in either project(modified and unmodified example).

    After testing, the connection will be abnormal with 7.5ms interval for the device with multiple connections.

    In this packet, the connection interval is 7.5ms.

    What is the impact of a 7.5ms connection interval?

  • 0 in reply to Shepherd Qu
    TI__Mastermind 42100 points

    Hi Shepherd,

    The connection interval is the time between connection events. 7.5ms is the smallest connection interval possible which will result in the minimum latency possible. If you are using multiple peripherals in a single connection, then it is recommend to use higher connection interval values The Connection Parameters section of the user's guide provides some information into how to select the ideal connection parameters for your project.

    Best Regards,

    Jan