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.

[参考译文] CC2564MODA:I2S 接口在传入呼叫时未激活

Guru**** 1744610 points
Other Parts Discussed in Thread: CC2564MODA, CC2564
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1192914/cc2564moda-i2s-interface-not-getting-active-on-incomming-calls

器件型号:CC2564MODA
主题中讨论的其他器件: CC2564

您好!

我们目前面临音频呼叫问题。

我们使用具有辅助模式固件的 CC2564MODA 模块、因为我们需要通过 I2S 向连接的 DSP 提供音频数据。
我们将在具有 BlueZ 堆栈的 Linux 下运行它。

因此、我们实施了所需的供应商命令、以根据我们的需求加载固件并配置模块、包括 PCM 接口。
到目前为止、它适用于 A2DP 和 HPF。

但是、在某些特定情况下、我们在为设备提供呼入电话时遇到问题。

我们的器件会对呼叫进行信号化和接受、看起来就像 SCO 信道已建立、但有时我们无法在 PCM 接口上获取音频数据。
接口保持未激活状态。 没有时钟处于活动状态。
根据我们的测试、问题似乎以某种方式与 CC2564MODA 的状态相关联。 如果它以前处于 A3DP 流模式、则可能会出现此问题。

因此、我想问您、在接受来电和重新配置系统时、我们是否需要考虑任何限制因素。

附件您可以找到从这种情况下生成的轨迹。 它显示了第一个呼入呼叫、我们的设备已标记并接受了该呼叫、但 PCM 上没有语音。 我通过在 PCM 接口上执行的跟踪验证了这一点。
挂断后,我们重复了该过程,第二次尝试成功。

目前、我们猜测可能会等待任何额外的信号、但对这两种情况的比较并未显示明显的差异。

您可能可以查看日志并分享您的意见?

此致、
Adalbert

e2e.ti.com/.../iCall1Fail_5F00_iCall2OK.zip

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

    您好!

    以下是有关我们的调查结果的一些其他信息。

    一旦我们处于故障状态(呼叫由模块建立并标记、但 I2S 不向外部 DSP 提供音频数据)、如果我们将电话上的音频路由从蓝牙更改为本地、然后再改为蓝牙、我们可以恢复 I2S 操作。

    从此前的调查中,我了解到,这部手机在切换回 CC2564MODA 时切断了 SCO 与 CC2564MODA 的连接,并在切换回 CC2564MODA 时重新建立了连接。
    在这种情况下、我们不会从侧面接触模块的配置。

    在我看来、在来电开始时对音频信道进行轻扫会干扰某些人、当来电信号化并且我们正在准备 I2S 信道时、他们会对配置进行干扰。

    我们已经尝试在前面可能的时间点配置 I2S、这似乎改善了情况、但并未消除根本原因。
    希望记录器跟踪可以揭示有关根本原因的更多信息。

    此致、
    Adalbert

    e2e.ti.com/.../7522.extSCOReroute.zip

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

    您好、Adalbert、

    感谢您提供的其他信息、我将查看日志、并告诉您是否有任何发现。 同时、我认为我们正朝着正确的方向努力、尽早配置 I2S。 请参阅随附的正确启用/禁用 A3DP 的 PDF。 您是否知道 PCM 使用哪些参数?   e2e.ti.com/.../CC256X-Advanced-Voice-and-Audio-Features.pdf

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

    Daniel、您好!

    我们使用 HCI_VS_Write_CODEC 配置(0xFD06)和 HCI_VS_Write_CODEC 配置增强型(0xFD07)命令来配置 PCM 接口。

    以下是我们在切换到电话模式时使用的数据:

    0xFD06:
    8kHz 帧同步速率、50%占空比
    RAW:8101 00 401f0000 01 00 1000 0100 00 1000 0100 00 1000 1900 00 1000 1900 00 00
    0xFD07:
    RAW:00 1000 2000 00 00 01 00 00feaf00 00 00 00 00 01 00 00feaf00 00 00

    到目前为止、我们尚未使用 WBS、因为附加的 DSP 尚未支持该功能。 因此、我们还不使用 WBS Asscociate 命令。

    此致、
    Adalbert

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

    您好、Adalbert、

    查看日志、我认为问题是、在第一个实例(左)中、流在配置有时间处理之前开始、而在第二个循环(右屏幕截图)中、SCO 链接会在之后进入。

    此外、发送的 HCI 命令是停止和关闭流、而不是打开和启动流?

    有关打开 A3DP 流的正确程序流程、请参阅下图。

    特别重要的是、以下注释取自我之前回复中的 PDF:

    "无法在流打开之前发送编解码器配置命令;因此、如果栈未接收到任何有关初始配置的进一步指示、则在发送打开命令后立即发送编解码器配置命令可能会很有用。

    需要注意的是、向控制器发出开放流命令是异步的;也就是说、协议栈必须等待控制器发出命令完成指示、然后才能将该流视为开放流。 在开放流进程中引入异步步骤可能会引入一些实现问题、例如何时通知较高(应用)层以及在流尚未打开时如何处理传入事件。 协议栈实施者需要处理此类问题。"

    您能否进行这些更改、并告诉我这是否解决了您的问题?

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

    Daniel、您好!

    非常感谢您提供本文档。 我们还不知道该文档。

    到目前为止、我们根据我们通过阅读蓝牙规范中的状态图所做的经验实施了我们的软件。 我们将实施建议的更改并执行一些测试。

    关于流打开命令:目前我不知道如何努力/可能获得 async 命令的响应。 是否有另一种方法来检查是否执行了流打开命令? 例如供应商命令?

    有关此控制器/控制器系列的可用文档的一般问题:
    您发送给我们的文档以及我们过去收到的文档似乎来自 TI wiki 页面、该页面已无法访问。
    该内容是否同时在网上提供?
    是否可以将所有文档重新调整到我们的模块中? 这可以帮助我们审查到目前为止所做的实施并避免进一步的问题。

    此致、
    Adalbert

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

    您好、Adalbert、

    您可能可以使用返回的 HCI_COMMAND_COMPLETE EVT 来确保执行异步事件、而无需知道主机堆栈可能会有一个中断、您可以在其中递增完成的命令数以知道何时打开了流?

    在文档端、我们目前正在努力将 TI wiki 页面转变为技术文档并上传以供公众访问。 虽然这可能令人沮丧、但请在需要时利用 E2E、我们将尽最大努力帮助您将文档带到 TI.com。

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

    Daniel、您好!

    这样就可以很好地使文档重新联机。
    关于异步事件:感谢您就此提出的建议。 我们在 Linux 上使用 BlueZ 版本5.62。

    此致、
    Adalbert

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

    Daniel、您好!

    调查表明、评估事件消息存在问题。

    在使用 hcitool 发送命令时,该工具正在等待事件返回,但它似乎没有验证事件是否与其发送的命令匹配。 这是我们将首先尝试调整地址的点、因为这会导致这样的情况:在旧命令被事件消息应答之前发送新命令。

    另一个问题:我们在一段时间前收到了有关模块特定于供应商的命令的文档。 它称为"CC256x VS HCI 命令"。
    是否有响应代码、通道/流命令回复的更详细信息?
    我们已经编写的文档只显示了可能的0x00和0x1-0xff 结果、而没有提供有关代码的更多信息。

    此致、
    Adalbert

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

    您好、Adalbert、

    据我所知、唯一详细的响应代码是与通用硬件关联的代码、请参阅下表、该表也包含在您提到的同一文档中: CC256x VS HCI 命令

    一般硬件错误代码 十进制值 十六进制值
    UART_HCI_NO_ERRs 0 0x00
    UART_HCI_ERR_NO_BUFFICS_COMMAND 1 0x01
    UART_HCI_ERR_NO_BUFFICS_ACL_DATA 2. 0x02
    UART_HCI_ERR_NO_BUFFICS_SCO_DATA 3. 0x03
    UART_HCI_ERR_NO_BUFFICS_EVENT 4. 0x04
    UART_HCI_ERR_NO_BUFFERS 5. 0x05
    UART_HCI_ERR_BAD_TYPE 6. 0x06
    UART_HCI_ERR_BAD_LEN 7. 0x07
    UART_HCI_ERR_LOCAL _RESET 8. 0x08
    UART_HCI_ERR_溢出 9. 0x09
    UART_HCI_ERR_奇 偶校验 10. 0x0A
    UART_HCI_ERR_FRAME 11.

    0x0B

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

    Daniel、您好!

    我看过这个表格、但我有一些疑问、这是正确的表格。 结果似乎毫无意义。
    我刚刚意识到、记录器本身也不使用此表来解码返回的错误。

    它似乎使用的是 BT 核心规范第1卷 F 部分中的标准错误代码描述。另一个强烈的指示是、我从某些命令中获得的错误代码超出了0x0d 的范围。

    同时、我们对软件进行了返工、使其能够可靠地等待发送的每个供应商命令的相应事件。

    但是、我们仍有呼叫音频缺失的情况。

    我将在有关主机和 CC2564固件之间交互的更详细的文档中介绍。 例如、如果收到 SCO 通道的连接请求、是否需要一些特殊的时间或操作?

    此致、
    Adalbert

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

    您好、Adalbert、

    遗憾的是 ,我们没有关于 SCO 渠道的更详细的文件。 至于相关信息、唯一需要注意的是 CC256X 高级语音和音频 Features.pdf 以及特定于供应商的命令 列表 e2e.ti.com/.../CC265x_5F00_VS_5F00_HCI_5F00_Commands.pdf

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

    Daniel、您好!

    看起来、等待正确的事件可以解决来电时 I2S 接口未激活的问题。
    感谢您在这方面的帮助。

    此致、
    Adalbert