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.

[参考译文] CC2640:使用 Android 5.0的带 GATT_Notification ()的 bleTimeout (0x16)

Guru**** 2564090 points
Other Parts Discussed in Thread: CC2541, CC2640

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/588054/cc2640-bletimeout-0x16-with-gatt_notification-using-android-5-0

器件型号:CC2640
主题中讨论的其他器件:CC2541

我在评估板上使用2.2.1 SDK。  我的应用程序通过 UART 每秒读取大约250字节,并通过调用 SerialPortService_SetParameter()通过通知消息将其发送到我的电话应用程序,如下所示。

UART 驱动程序只需将数据复制到270字节循环缓冲区中、一个5ms 事件一次可将数据拉至80字节、4个20字节的块、并将其发送到手机。  我们之前的设计使用的是 CC2541、它在包括 Android 5.0电话在内的所有电话平台上都是稳定的。  我们目前正在升级到 CC2640、因此我将首先在评估板上运行该设计。 此设计在 Android 6和 IOS 10上保持稳定。  使用 Android 5时、我可以运行10到15秒、然后获得 bleTimeout、返回代码0x16、系统在我重新连接之前死机。   如果我将设计修改为每80ms 只写入2个20字节的缓冲区、那么它会运行更长的时间、但偶尔会停止30秒、然后恢复使用。

问题:

  1. 由于我正在向电话发送通知消息、导致 bleTimeout 的原因是什么?
  2. 当我获得 bleTimeout 时、是否有任何恢复方法?
  3. 为什么当我降低油门时、系统会停止30秒、然后恢复?

谢谢、

John

代码片段:

静态 bool PumpDataToPhone (void)
{
uint16i;
uint16uLen;
bStatus_tRetVal;
boolBRTN;

BRTN = false;

if (s_uPhoneTxBuffHead!= s_uPhoneTxBuffTail)
{
//我们处于活动状态...
BRTN = true;

//尝试输出4 20字节缓冲区...
for (i = 0;i < 4;i++)
{

if (s_uPhoneTxBuffHead > s_uVal TxBuffTail)
{
uLen = s_uVal TxBuffHead - s_uPhoneTxBuffeter;
}
否则
{
uLen = sizeof (s_uVal TxBuff)- s_uPortTxBuffeter











(uTX_uTX_uTXT = uTXT);}uTX_uTX_S=uTX_uTX_uTXT = uTXT = uTXT = uTXT 缓冲区;}uTX_uTX_uTX_uTXT = uTX_uTX_uTXT = uTXT = uTXT = uTXT = uTX_uTXT = uTXT = uTXT = uTXT = uTXT = uTXT = uTXT = uTXT = uTXT = uTXT = uTX

if (s_uPhoneTxBuffTxTail >= sizeof (s_phoneTxBuff))
{
s_uPhoneTxBuffTxTail = 0;
}


if (s_uPhoneTxBuffTxTail = s_uPhoneTxBuffHead)
{
//没有更多要发送的内容...
break;
}

否则
{
Display_Print1 (dispHandle、4、0、"JDO 通知错误:%d"、RetVal);
break;
}

}

返回(BRTN);
}

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

    我会尽力回答您的问题、如果我错过了任何内容、我也联系了一位串行数据专家。

    1.由于我正在向电话发送通知消息,导致 bleTimeout 的原因是什么?
    当正在进行 GATT 操作时、会出现超时。 这包括通知/读取/写入/等

    2.当我收到 bleTimeout 时,是否有任何恢复方法?
    尝试重新传输,或者可能缩短连接间隔。 您可以附加监听器捕获吗?

    3.为什么当我踩下油门时,系统会停转30秒,然后恢复?
    很难说。 监听器捕获这两个事件有助于查看发生的情况。

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

    感谢您的快速响应。  

    1. 通知为什么会导致我认为它是发送和忘记的超时?  

    2. 我尝试重新传输、但没有任何结果。

    3.参见随附的捕获。

    4.是否有任何方法可以事先确定硬件是否繁忙,我不应该尝试发送?

    我已附上 TI 数据包监听器的数据包捕获。  在此捕获中、我每80 ms 发送2个2字节的数据包。  数据包20602是传输的最后一个数据包。  

    我的测试数据包为246字节、从0xAE F1 0E 52 00 01 02到0xF0 、cksum 为0xC0。

    e2e.ti.com/.../Android5_5F00_TechDataError.psd

    谢谢、

    John  

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

    很抱歉、我以为我们一直在谈论"白令人发指"、这里的超时毫无意义。

    1.它们通常是发送和忘记的(在控制器实际发送它们之后,您可以忘记它们)。

    我注意到在您的环境中重试了很多次。 直到控制器发送通知、而另一个控制器已确认通知;控制器将处于忙状态。

    通知本身不会在任何更高级别得到确认-

    2.您尝试重新传输、但您是否遇到了等待处理的问题? 或任何其他错误代码?

    3、仍然说得太难了。 您能否使用 simple_central 和 simple_peripheral 重现此问题?

    4、除了尝试调用另一个 ATT 函数之外、我不确定。

    我必须深入了解这一点、然后再返回给您

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

    您提到了许多重试次数、能否指出具体的数据包编号?  例如、发送的最后一个数据包是20602、但我看不到它被重试。

    我没有其他错误代码、只是0x16。

    我没有尝试使用 simple_peripheral/central 组合进行重现。  我只有一个评估板可供我使用。

    谢谢、

    John

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

    如3374或3554、它们似乎是随机的。

    我必须深入研究这一点、以了解导致错误代码的原因。 我想我今天不能得到您的回复、但肯定是下周。

    您可以获得一个额外的评估板吗? 我必须能够重现您的问题、才能完成更多工作。

    我们有一个吞吐量示例、使用通知作为数据传输的手段、它不会出现您所看到的问题。

    同时、您也许可以尝试复制吞吐量示例 中所做的工作:github.com/.../cc2650lp

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

    反叛分子,

    感谢您的帮助、但我发现了问题、但我还不理解。  我的设计从 https://github.com/ti-simplelink/ble_examples 上的 SPP 示例开始

    UART Rx 缓冲器为128字节、处理程序似乎禁用并重新启用中断。  出于某种原因、仅对于 Android 5、UART Rx 会停止、然后我会得到一个 bleTimeout。  

    作为变通方法、我只是将 Rx 缓冲区大小 UART_ISR_BUF_SIZE 从128字节增加到270字节、使其大于我的最大消息、现在一切都正常。  我需要返回并重新访问 UART 处理程序、以查看是否还有另一个问题需要解决。

    谢谢、

    John