[参考译文] CC2651R3SIPA：ATT 通知数据中断

您好、

感谢您的联系。我们将查看您的问题,并尽快回复您。

此致、

1 月

你好、 冈崎！

有几个调试步骤,我会尝试确定问题:
-你可以检查 ATT_HandleValueNoti函数是否返回一个非零值?
-您可以尝试使用 GATT_Notification 函数而不是ATT_HandleValueNoti,看看它是否解决了问题? 它是否返回非零值？
-您使用的是哪种 BLE 监听器? 您是否可以访问您可以使用进行测试的另一个 BLE 监听器？
-接收通知的中心是否收到正确的数据? 如果没有,外围设备是否接收到与嗅探器接收到的完全相同的数据?

此致、
Maxence

你（们）好

非常感谢您的答复。

-你可以检查 ATT_HandleValueNoti 函数是否返回一个非零值?

GATT_Notification 用于 host_test。  全部返回零。

-您可以尝试使用 GATT_Notification 函数而不是 ATT_HandleValueNoti,看看它是否解决了问题? 它是否返回非零值？

我找到了以下代码、可以使用  ATT_HandleValueNoti API

/*以下 API 目前不可用*/
#define ATT_HandleValueNoti (...) (AssertHandler (0、0)

-您使用的是哪种 BLE 监听器? 您是否可以访问您可以使用进行测试的另一个 BLE 监听器？

BLE 监听器是 Ellisys。 但另一个 BLE 监听器没有。

-接收通知的中心是否收到正确的数据? 如果没有,外围设备是否接收到与嗅探器接收到的完全相同的数据?

中央接收错误数据、因为包含错误数据的数据包不是数据包错误。

此致、

冈崎市

您好！

您能否与 GATT_Notification 共享用于发送通知的部分代码 ？ 我正在阅读文档,分配给这个函数的内存必须分配与 GATT_BM_alloc (),也许你忘了这样做?

此致、
Maxence

您好、

非常感谢您的答复。

我们的软件基于 host_test。

GATT_Notification 代码位于 iCall_HCI_tl.c 中的屏幕截图下方

我不修改任何内容。

此致、

冈崎市

您好！

由于您的项目基于 host_test、您能否在使用默认 host_test 项目时检查是否也看到了问题？ 您对 host_test 项目进行了哪些修改以满足您的需求？

此致、
Maxence

你（们）好

以下是与原始 host_test 的区别。

- GATT 服务数据库已修改

-添加缝隙债券管理器

- RCOSC 已启用

-缓存已禁用。 它会分配 npi_rxbuf.o (.bss) 和 npi_tl.o (.bss)。

- UART 波特率更改为 150kbps

- UART 端口已更改为 DIO2、DIO0-DIO3

-添加 LED 控制计时器

-Bootloader Backdoor DIO 更改为 3

很难由默认的 host_test 工程进行检查

因为它无法连接。

我尝试了下面的部分默认 host_test 工程配置。

它不是改进。

- RCOSC 已禁用 (x)

- UART boudrate 更改为 115.2kbps (x)

-删除 LED 控制计时器 (X)

此致、

冈崎市

您好！

当你说“中央接收错误数据,因为包包括错误数据不是包错误“,你是指中央接收错误的数据,但不把它标记为错误?

BLE 数据包在数据包末尾附近包含 CRC 值、以确保数据不会因传输过程中发生的任何扰动（繁忙的无线电环境，墙壁，金属等）而损坏。 因此、如果在传输过程中发生问题、则会产生不正确的 CRC 并由中心器件丢弃。 但是、如果中央器件接收到数据并接受数据、则 CRC 有效、问题会更早发生。

在正确的 ATT 数据包中   、您将依次发送 01 和 1B、这是您在 BLE 中读取的 ATT_VALUE_NTF 的属性（ATT 规格）

是否所有的数据包都以“01 03“开头？ 您可以发送多个数据包的样本吗?

此致、
Maxence

你（们）好

请查找附件。

此日志是使用 TI 评估板 LP-CC2651R3SIPA 捕获的

例如、Packet # 40,838、CRC 正常、数据中断

我认为是相关的 LE 数据长度。 当我们的产品板时、许多数据包都已损坏。

e2e.ti.com/.../Send_5F00_DataBroken.zip

此致、

冈崎市

您好、

我要试着看一看。

与此同时,当你说“当我们的产品板,许多数据包被破坏“,你意味着什么? 是什么让您认为它与 LE 数据长度相关？

此致、
Maxence

你可以尝试的另一件事是打印你在 pBuf[2]中的值,以确保它不会在某个地方被修改。

您好！

根据我发送给我们的 BLE 监听器日志中可以读取的信息、我可以看到一些数据包（一些百分位数）确实已损坏。

对于错误的数据包、感觉发送的数据包被截断了。 L2CAP 标头指示 183 字节的有效载荷、但有效载荷实际上要短得多。 这些错误数据包的 CRC 值无效。

我认为可能由于数据包很大（187 字节的数据）、它会被拆分成多个帧、使其大小低于 MTU 大小。 是否可以尝试增加最大 MTU 大小并查看是否有任何更改？