• 状态 Resolved
  • 已锁定 已锁定
  • 回复 9 回复
  • 订户 0 订户
  • 视图 370 视图
  • 用户 0 会员在此处
选项
选项
相关

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：配对失败&quot；只工作& quot；和芯片 R2

admin
Guru**** 2587365 points
Other Parts Discussed in Thread: CC2640, CC2640R2F, BLE-STACK

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/569617/cc2640r2f-unsuccessfull-pairing-just-works-and-chip-r2

器件型号：CC2640R2F
Thread 中讨论的其他部件：CC2640、 BLE-STACK

你(们)好


我们正在从具有堆栈的旧 CC2640芯片迁移：BLE_cc26xx_2_01_01_44627
更改为具有协议栈的新型 CC2640R2芯片：[SimpleLinkTmCC2640R2 SDK 1.00.00.17.eng]

对于旧设置、"正常工作"配对正常(2个 LaunchPad、1个中央应用程序、1个外设应用程序)、但对于新设置、我们卡在"加密请求/RSP"序列中间。

请参阅随附的空气嗅探器。

如果我理解正确、配对过程中完全不涉及我们的应用、那么我需要一些支持、以使 BLE 堆栈停止无线通信？

构建堆栈时、我是否需要调整一些设置？

我将堆栈构建为二进制(旧方法)而不是库。

我在 ROM 中使用堆栈、但在闪存中构建 TI-RTOS。

这是 我使用的预处理器定义为： 

CC26XX
CC26XX_R2
DEVICE_family=cc26x0r2
EXT_HAL_ASSERT
FLASH_ROM_Build
GATT_NO_CLIENT
ICALL_Events
ICALL_JT
ICALL_Lite
OSAL_CBTIME_NUM_TRIGGER_TES=2
OSAL_SNV=1
power_Saving USE_CORE_SDK_USE_ICALL_ICALL_Lite

函

数 ICALL_SEND_MAX_TRIGGALL_PROJESS_NUM_4 OSAL_PROJEST_TRIGGPTS 任务

e2e.ti.com/.../Pairing_5F00_NOK_5F00_CentralR2_5F00_PerR2_5F00_JustWorks.zip

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

    要获取一些背景信息、您是否从现有 CC2640R2 SDK 开始、然后遵循移植指南？ 此外、您是否在移植到 CC2640R2 SDK 之前将应用从 BLE-STACK 2.1移植到 BLE-STACK 2.2 (因为 CC2640到 CC2640R2F 移植指南假定从 BLE-STACK 2.2移植)？

    －弥敦
  • 0
    TI__Guru**** 2587365 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好！

    我可以从您的评论中看到、您正在使用预发布版本的堆栈。 请使用官方版本并查看其是否仍然不起作用。

    官方 SimpleLinkTmCC2640R2 SDK 1.00.00.22可从 ti.com/ble-stack 下载
  • 0
    TI__Guru**** 2587365 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Christin

    感谢您的提示。 我们将从将 SDK 升级到最新版本(22)开始。

    同时、我们这样做时、您能否了解一下 IAR 调试器的屏幕转储(进一步向下)和先前帖子中的监听器日志。
    我们注意到堆栈任务似乎设置了一个120ms 的计时器。 这对应于 R1芯片配对正常时的监听器日志。 在 SMP 层外设中、先发送"加密信息"、然后发送"主标识"(之后为120ms)。 在 R2情况下、当它挂起时、我们只会看到"加密信息"、并注意到、根据 IAR 屏幕转储、有一个120ms 的时钟设置、就像堆栈任务由于某种原因从未获得这个超时一样？ 在配对尝试之前和之后附加了任务选项卡、如果这可以为您提供更多线索。

    名为"scheduler_taskFxn"的任务会切换 Launchpad 板上的 LED。 当我们遇到配对挂起问题时、此切换通常也会停止工作(9/10次)、就像任务被淘汰一样。

    正常情况–外设–配对挂起前

     

    配对挂起后

     

     

    BR。

    Erik

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

    你(们)好

    现在、我们使用官方 SDK cc2640r2_sdk_1_00_00_22进行了测试

    遗憾的是、仍然存在相同的误差。

    我们看到了这个论坛问题，它看起来非常像我们所面临的同样的问题。

    https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/t/550961

     

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

    在监听器日志中、配对请求和响应的身份验证请求均为0x00。 这意味着、除其他外、您不会请求绑定。 该设置是否与您的 R1 (CC2640)实现一致？

    在我们的默认 simple_peripheral 中、我们具有以下内容：

    uint8_t 绑定= true；
    GAPBondMgr_SetParameter (GAPBOND_BUSIONIND_ENABLED、sizeof (uint8_t)、&bonding)；

    您是否可以在设置中进行同样的确认？

    祝你一切顺利
  • 0
    TI__Guru**** 2587365 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你(们)好

    为了首先回答您的问题、我们禁用绑定以使身份验证尽可能简单、从而能够发现错误。 只需避免 SNV 出现潜在问题。

    很高兴我们发现了这些问题。

    首先、我们再次详细研究您的示例代码、发现我们错过了以下代码条： 

    #ifdef ICALL_JT
//更新堆栈的用户配置*/
user0Cfg.appServiceInfo->timerTickPeriod = Clock_tickPeriod；
user0Cfg.appServiceInfo->timerMaxMillisecond = iCall_getMaxMs ()；
#endif /* ICALL_JT *
    • 这解决了外设端在"加密信息"消息之后停止通信的问题。 请参阅空气嗅探器。 此更改后、它继续执行其余具有120ms 增量的解密设置命令。 您能给我解释一下该代码的真正作用是什么吗？

    修复后、我们在监听器中注意 到显示了所有加密消息、但我们仍然没有从堆栈中获得最后一个 GAPBOND_Pairing_State_Complete 事件。

    经过长时间调试后、我们注意到在初始搜索错误期间、堆栈构建的"OSAL_CBTIMER_NUM_TASES=2"发生了意外更改。 (如我的初始帖子中所示)
    我们偶然发现 osalInitTasks( void )中的初始化代码

    • 当 OSAL_CBTIMER_NUM_TASES=2时、我们很想知道该代码是否真正按预期工作。 您可以尝试设置=2并对其进行测试。  
      对于未来的发展、我们是否需要将此值更改为2？ 如果是、在哪种情况下应该是这样、在这种情况下、我们是否需要在应用代码中执行某项操作？ 
    #if defined (OSAL_CBTIMER_NUM_TASK任务)
/* Callback Timer Tasks */
osal_CbTimerInit( taskID )；
taskID += OSAL_CBTIMER_NUM_TASKS；
#endif

    无论如何、我们再次将其更改为=1、现在它看起来像在 R1芯片中一样工作。

    BR。

    Erik

  • 0
    TI__Guru**** 2587365 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我是否会获得有关这个的任何反馈？ ？
  • 0
    TI__Guru**** 2587365 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 Erik、

    这些更改是 CC2640R2 SDK 中 ICall 转换模块平台改进的一部分。 因此、我们的迁移指南建议使用 CC2640R2 SDK 项目作为基础、并将修改内容从以前的 SDK 移植到此版本。 具体而言、您在项目中定义了 ICALL_JT、因此正确初始化 OSAL 计时器子系统需要此代码。

    对于 OSAL_CBTIMER_NUM_TASks、堆栈项目的默认设置为1。

    祝你一切顺利
  • 0
    TI__Guru**** 2587365 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    哇，谢谢！！！ 对我来说也是一样的，花了我一整天直到我找到这篇文章。 在无用的 TI 移植指南中甚至找不到这一点。 TI 员工、您需要解决这个问题。