[参考译文] CC2642R：来自 SimplePeripheral 的按类型读取请求的无限 ATT 循环(CC2640R2F 相同)

您好、Marie、

我深入探讨了它、可以向您展示生成了 ATT_ERR_UNSUPPORTED_REQ。

[删除了代码片段]

CC2540上的常规中央设备不会调用  GATTServApp_Init() ，因此  reqTaskId 保持其默认 的 INVALID_TASK_ID。

当  在  gattServerProcessMsgCB()中处理服务器消息 并且将此错误代码发送到连接的外围设备时，这将导致返回 ATT_ERR_UNSUPPORTED_REQ。

它将 GATT_SERVER.c 与最新的 CC26x2 SDK 3.10.00.53与 CC2540的 GATT_SERVER.c 进行了比较、并可以看到  gattServerProcessMsgCB()中的行为仍然相同。

因此、如果您有一个不调用  GATTServApp_Init（)的简单中央设备、则 CC2642R 上也会检测到相同的行为。

[删除了代码片段]

因此、无论是 TI 中央器件发送错误的 ATT-Error-Code (CC2540和 CC26x2)、还是 TI 外设器件都存在导致无限请求的错误。

我使用 CSR 的另一个旧 BT4.0中央设备进行了测试。

当 CC26x2尝试读取 RPAO 和 CAR 时、它会以"未找到属性"进行响应。

。 因此、我想 TI 在没有 GATT 服务器的情况下实现中央设备的行为是错误的。

请在下面找到 Ellisys 文件。

e2e.ti.com/.../RPAO_2B00_CAR-read-from-CSR_2C00_CC2652_2C00_SDK_5F00_2_5F00_40_5F00_00_5F00_81.zip

您好 Tobias、

对于 TI BLE-Stack GATT 服务器应用、必须使用 GATT Service/GATT 服务器应用。 我们没有任何不使用它的示例。 您可能可以实现不使用 GATT Server 应用但我们不建议使用 GATT Server 应用程序的 GATT Server、并且无法为开发提供支持。

您好、Marie、

[引用 user="Marie H">我们没有任何不使用它的示例。 [/报价]

这不是真的。

请允许我总结一下我们的情况：

我们的一款产品基于 CC2642R、充当 BLE 外设和 GATT 服务器 (我们也拥有基于 CC2541和 CC2640R2F 且具有相同功能的类似器件；现场器件总数超过10.000.000)。

另一个产品基于 CC2540、充当 BLE 中央设备和 GATT 客户端。 让我简化一下：它将通知转换为 HID 报告。 此产品基于 BLE-Stack 1.4.1中的示例 HidRemoteDongle (源代码、而不是预编译库)。 此示例根本不支持 GATT 服务器-它不调用 GATTServApp_Init()。

现在、我们有一个 MP 产品、它基于您的示例 HIDRemoteDongle、该产品没有 GATT 服务器、因此与您最新的 BT5堆栈示例不兼容。

在 BT5堆栈的 GATT 客户端实现中使用一段代码来防止卡在 ATT 读取请求的无限循环中是否是一个好主意？

此致、Tobias

玛丽、

您是否看过我提到的示例？？？
[引用用户="Tobias_r"] 此产品基于 BLE-Stack 1.4.1中的示例 HidRemoteDongle (源代码、而不是预编译库)。 此示例根本不支持 GATT 服务器-它不调用 GATTServApp_Init()。
[/报价]

该示例称为"HidAdvRemoteDongle"、而不是"simple_central "。
该示例来自德州仪器。
该示例不调用 GATTServApp_Init()。
该示例没有 GATT 服务器。
该示例导致 CC2642R 的 simple_peripheral 出现问题。

请注意、涉及两种 TI 产品(查看我的帖子)。
基于 HIDRemoteDongle 的 CC2540 (大规模生产！)
2. CC2642R 使用了外设。


CC2642R 与基于 TI 和 TI 示例的 CC2540进行交互时出现问题。
因此、TI 软件中存在问题。