• 状态
  • 已锁定 已锁定
  • 回复 8 回复
  • 订户 0 订户
  • 视图 381 视图
  • 用户 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.

[参考译文] CC2564：在 CC2564B A2DP SBC 设置期间丢失 RFCOMM 数据包

admin
Guru**** 2584125 points
Other Parts Discussed in Thread: CC2564C

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/634505/cc2564-lost-rfcomm-packets-during-cc2564b-a2dp-sbc-setup

器件型号：CC2564

我们相信我们发现了我们使用的 CC2564B 蓝牙芯片的问题，我想看看是否有其他人以前发现过这种问题。

当 A2DP 音频打开或关闭时、芯片可能会丢失数据包。  这似乎只在控制器进行自身配置时发生。  我们看到它丢失了 RFCOMM SPP 数据和信用。  如果我们禁用 A2DP (甚至仅限 TI 控制器中的 SBC 解码器)、此丢包问题就会消失。

我确认我们使用的是最新的补丁。  这是芯片的已知问题吗？  也许在更新的 CC2564C 版本中解决了这一问题？

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

    CC2564B 或 CC2564C 中不会出现此问题？ 您是否有任何日志显示此问题的捕获？

    您使用的是什么主机 MCU 堆栈？

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

    我们使用的是在 STM32F429中运行的 Dotstack。

    我很快就会发布一些日志。

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

    Vihang、您好、我已附上以下日志、以显示比上一个日志更清晰的信息。   

    当电话请求启动流时、问题就会开始。 这是堆栈日志中的第一个数据包。 耳机配置控制器。

    配置在第3页完成、并显示"PCMPORT_PA：A3DP 流已启动"消息。 现在、手机正在流式传输、控制器播放音频。

    此时、Solos 应用程序会发送图像。 图像的第一个片段位于第4页。 我用绿色突出显示了构成图像的所有数据包。 应该有16个片段。 中的数字

    BPA600日志为：13831、13833、13835、13853、13855、 13857、13880、13947、13949、13951、 13953、13979、13981、13983、13987、 14010. 堆栈的日志缺少其中两个：13880和14010。

    在发送图像的所有这段时间、电话也在发送音频。 停止流的请求位于第29页。 数据包似乎不仅在配置控制器时丢失、而且在处理音频帧时丢失。

    e2e.ti.com/.../missing_5F00_rfcomm_5F00_frames_2D00_3.zip

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

    您是否有机会浏览这些日志？  谢谢！

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

    John、

    很抱歉耽误你的时间。

    我了解了监听器捕获和您的笔记。 对于丢失/丢失的射频帧、我看到 CC2564B 确实向主器件发送了基带层 ACK。 遗憾的是、监听器日志不足以调试此问题。 下一步、我建议将相同的监听器日志与 CC256x FW 日志(说明)一起捕获、以便在两个日志之间进行相对时间同步。 这样，我们就可以更深入地了解主机为什么没有看到这些 ACL 数据帧。

    此致、

    Vihang

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

    Vihang、您好、我们已根据您的要求再次使用其他 CC256x FW 日志重现了该问题。  一些背景信息：

    测试应用(在手机和堆栈上)会尽可能快地发送数据。 来自电话的数据包具有结构-一个标头和一个数据部分。 标头包括序列号。 该问题在堆栈接收到的数据包#11176之后发生。 在堆栈的日志中、这是第450170行。 在 BPA600日志中、这是帧#94074。 此帧包含数据包#11176的最后一个片段和数据包#11177的起始部分。 包含数据包片段并被堆栈接收的下一帧为#94078 (堆栈日志中的行#450179)。 这是最后一个包含堆栈接收到的数据的 RFCOMM 帧。 之后、电话再发送4个帧- 94095、94097、94099、94101 -但这些帧未发送到堆栈。 因此、堆栈从未向电话发送过点数。 现在手机的信用为0、所以它停止发送。

     出现问题时、电话正在流式传输音频。 流处理从堆栈日志中的#448112行开始、并在#454880行结束。 在控制器的日志中、这对应于从帧#42984到#43291的范围。

     e2e.ti.com/.../missing_2D00_frames_2D00_log_2D00_02112017.zip

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

    有任何有关这方面的新闻吗？

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

    您好、John、

    对拖延表示歉意。 您提供的 FW 日志和监听器日志在分析问题方面确实提供了很大帮助。 AVPR 似乎以某种方式将这些缺失的数据包误解为 AVDTP 数据包。 因此不会向下发送到主机。
    我们正在评估这种竞争状况的可能修复方法。 我会随时向您发布进度信息。

    此致、
    Vihang