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.

[参考译文] CC2340R5:连接监视器出现 4 个连接问题

Guru**** 2538960 points
Other Parts Discussed in Thread: CC2340R5

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1530048/cc2340r5-connection-monitor-with-4-connections-issue

器件型号:CC2340R5

工具/软件:

尊敬的 TI 专家:

执行 4 连接监控测试时、如果我重复断开其中一个连接、在大约 4 小时后、SDK 开始持续报告断开的会话的 CM_FAILED_NOT_ACTIVE 错误(大约每 1ms)、即使会话应该已正确终止也是如此。

环境: ​

  • 器件:CC2340R5
  • SDK 版本:8.40.0.61.

观察到的行为: ​

  1.  MicroCmApp_monitorCompleteEvt () 函数进入保持接收 CM_FAILED_NOT_ACTIVE 状态的状态
  2. 日志显示重复错误:“cm_failed_not_active id 错误:65535、会话:X 可能会话已关闭“
  3. 如果没有完全重新启动、系统将无法从该状态恢复
  4. 即使尝试重新启动监控也不会阻止错误泛洪

尝试的解决方案: ​

  1. 已验证在终端周围的互斥量处理是否正确
  2. 已确认会话 ID 有效性检查
  3. 已尝试手动重新启动监控
  4. 已验证 SDK 版本兼容性

问题: ​

  1. 这是 SDK 8.40.0.61 中的已知问题吗?
  2. 是否有任何权变措施来防止此错误泛洪?
  3. 处理 CM_FAILED_NOT_ACTIVE 时是否应执行额外的清理?
  4. 是否有在多连接情况下处理重复断开连接的建议做法?

代码:

日志:

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、

    感谢您与我们联系并提供有关此方面的详细信息! 您能否分享您对 CM 工程所做的修改?

    此致、

    1 月

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    1、数据接收入口点

    修改目的

    绕过 SDK 的 RTLS 控制依赖项并建立 LIN 总线、如所示 ​唯一数据源 ​用于监测。

    密钥代码更改

    //原始 SDK 代码(禁用):

    // MicroCmApp_processRtlsCtrlMsg ((uint8_t *) pEvt->pData);  

    //我的修改(在 MicroCmApp_processMicroCmAppMsg ()):

    switch(pEvt->event){

        case micro_CM_APP_CM_EVT: //仅处理 BLE 栈事件

            MicroCmApp_processCmMsg ((uint8_t *) pEvt->pData);

            休息

        //故意忽略 MICRO_CM_APP_RTLS_CTRL_EVT

    }

    效应

    • 禁用 RTLS 控制路径 (RTLS_REQ_CONN/RTLS_REQ_TERMINATE_LINK)
    • 通过  app_lin_data_management () 强制所有监控触发器来自 LIN 总线

    2.监控激活条件

    修改目的

    确保 ​参数完整性 ​在激活监控之前、使用经 CRC 验证的 LIN 总线数据。

    密钥代码更改

     

    //在 app_lin_data_management ():

    Uint8_t bus_param[18]={AA_0 ()、AA_1 ()、...、ROLE ()};// LIN 参数

    uint16_t CRC_calc =__CRC16_8005 (bus_param、sizeof (bus_param));//计算 CRC

    if (crc_calc == lin_bus_manage_info_s.crc_param){//验证 CRC

        //仅在 CRC 匹配时更新参数

        monitor_ctrl_info[device_id].monitor_para.ble_info.accessAddr = bus_param[0]|(bus_param[1]<< 8)|……;

        monitor_ctrl_info[device_id].monitor_para.run_state =(bus_param[15] 0x08)>> 3//提取 run_state

        

        //有条件地启动/停止监护

        app_exec_cm_process (device_id);

    }其他 {

        CC_printf(“CRC 不匹配! 预期:%04X 实际:%04X\n“

                  lin_bus_manage_info_s.crc_param、crc_calc);

    }

    关键逻辑

    1. CRC Guard 条款 :拒绝损坏/不完整的 LIN 数据
    2. 原子参数更新 :仅在 CRC 检查后复制所有参数(AA、interval 等)
    3. 状态驱动的执行 run_statebit 确定  app_exec_cm_process () 是 启动还是停止监视

    3、核心监控逻辑

    (未重复代码的汇总)

    • 螺纹安全 : pthread_mutex_lock  (&cm_opt_mutex) 中包含的所有 ubCM_*调用
    • 通道验证 :带有错误计数的实时跳频序列验证
    • 超时控制 :通过  MONITOR_TIMEOUT_COUNT 自动终止

    与 SDK 相比的关键改进

    方面

    原始 SDK

    我的 实现

    数据源

    RTLS 控制消息

    LIN 总线+ CRC 验证

    激活

    根据 RTLS 命令立即执行

    取决于 CRC+RUN_STATE

    螺纹安全

    不保证

    受互斥量保护的所有操作

    错误处理

    基本故障报告

    CRC 检查+同步验证

    此版本将重点介绍您的架构转变 ​事件驱动的 RTLS 控制 ​最终目的 ​LIN 总线管理的状态机 ​验证功能。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    这是您所使用的 SDK 版本中的一个已知问题。 此错误已在 9.11 版 SDK 中修复、您可以 在此处下载

    此致、
    Maxence