[参考译文] CC2564MODN：CC2564MODN I2S 配置问题

Jason、

我们将回顾音频配置并返回。 请查看数据表中的第6.4.3节- www.ti.com/.../cc2564c.pdf
您可以将通道的位位置配置为仅从编解码器中选择24位 PCM 的16位(MSB)。

谢谢

好的、我认为编解码器配置得更好一些、但 CC2564MODN 在16位帧的末尾不会将音频总线驱动为低电平。  ADAU1772编解码器不支持16位模式、因为 CC2564在音频通道之间需要一个等待块、因此我担心偶尔会拾取下降线并将其解释为较低阶的噪声位。  我们还观察到编解码器的自动增益控制变得混乱、并开始意外停止。   

随附的波形显示了 CC2564如何让其1通道16位音频数据的线(黄色轨迹)移动。  蓝色轨迹线是24位 ADAU1772的两个通道。  

这是添加了10K 下拉电阻的情况。  我们将尝试使用1K 下拉电阻器、但更好的解决方案是让 CC2564通过将线路驱动至正确状态来校正它。   

谢谢、

Jason

嗯、使用1K 我能够使压降几乎完全消失、但仍然不同步。

当处于双 SCO 模式时、输入和输出通道上的音频均清晰可见。 但是、有时连接到第二个 SDO 通道的手机会翻转并开始发出快速的大咔嗒声。 如果我让将两个音频通道驱动到 CC2564的编解码器对该通道进行静音/取消静音、点击会消失、但可能会稍后回来。 权变措施是每秒使编解码器静音/取消静音、然后这并不是真正的问题、但这是一种解决此问题的可怕方法。

在此期间、I2S 数据看起来格式都正确、我想知道这是否是 CC2564不跟上的结果？ 以前见过类似的东西吗？ 在此期间、从手机传输到 CC2564的音频以及与第一个连接的 SDO 器件之间的音频通道都是清零的。


谢谢、

Jason

您好 Jason、

阅读以上描述、数据输入/输出边沿选择可能会导致您偶尔观察到的嘀嗒声。 除了两个通道的数据输入/输出偏移之外、您还可以将 CC256x 配置为使用位时钟的上升沿或下降沿来采样/置位数据(取决于数据输入/输出信号)。 一般的想法是在 CC256x 上使用与音频编解码器所使用的边缘相反的边沿。 在上述逻辑线路的屏幕截图中、系统中的 ADAU1772编解码器在 BCLK 的下降沿将数据置为有效。 因此、CC256x 上的数据输入边沿(对于两个通道)应配置为上升边沿。 这样、线路上的高电平-低电平转换不会导致另一个器件上的数据包损坏。 请修改您的编解码器配置设置、以确保在两个方向上都选择了相反的边沿。

此致、
Vihang

Vihang、您好！

  是的、我知道编解码器必须配置为在适当的边沿正确计时输入/输出数据。  我相信我们已经正确配置了这种配置、两个器件都在上升沿接受数据。  作为一项快速测试、我尝试调整边缘、这只会导致整个系统中的耳罩破裂。  ADI 正在协助他们完成复制设置以排除编解码器发生的任何异常情况、或任一部件配置错误。   

  附加的一些屏幕截图显示了左声道和右声道。  黄色为 FSync、绿色为 BCLK、紫色为 CC2564MODN、青色为 ADAU1772编解码器。  这些参数是在持续的情况下获得的、以更好地说明边沿转换、我使用垂直光标来标记上升边沿转换。  

   请注意、紫色 CC2564只是让它离开线路而不将其归零、这可能会有所帮助... 这添加了1K 下拉电阻。

  我们遇到问题的正确信道(电话)中有一个伪迹、在电话中尖叫无法更改3个最高顺序位。  但是、对着 ADAU1772的麦克风输入尖叫会切换最高顺序的位。  不确定是什么原因、但它与我们的问题没有直接关系、因为手机的音频质量不错。  它仅是电话的音频已损坏。

  我将在下周提供 ADI 的结果可用时、以及在我们有时间测试时钟边沿之后的更新。    

左侧(Bluegiga 底座)  

右(电话)  

谢谢！  

 Jason

您好 Jason、

感谢您的更新。 我将关注该主题、了解您的其他结果。

[引用用户="Jason Gossiaux]  请注意 、紫色 CC2564只是让它离开线路而不将其归零、这可能会有所帮助... 这是添加了1K 下拉电阻的情况。[/quot]

您能详细说明1K 下拉电阻吗？ CC256x 上的 I2S/PCM 引脚已经有一个内部下拉电阻器。 有关详细信息、请参阅器件数据表中的引脚属性。 您能否再次检查您的系统设计是否符合数据表(和 EVM 设计文件)中提供的参考原理图？

此致、

Vihang

Vihang、您好！

 如果您参考图 6-1原理图。 参考原理图、那么是... 我们只有一条迹线、没有其他组件将来自 CC2564MODN 的 AUD_*信号连接到编解码器。  两个器件均为1.8V 逻辑电平、因此无需隔离或电平转换。   

  在具有从 CC2564MODN 到其他编解码器和 MCU 的多个 I2S 接口的多种设计中、我们观察到音频传输完成后、音频输出信号无法快速稳定、尽管如此(从示波器捕获中可以看到) 在数据传输过程中边缘清洁且快速转换的应用。  只有当输出变为高阻态时、I/O 才会花费时间稳定。   存在什么值的内部下拉电阻？  数据表似乎没有具体说明它。   

我们的设计中没有额外的下拉电阻器、因为我们依赖 CC2564MODN 的内部下拉电阻器。  但是，考虑到我们当时的问题，我们决定采用一个模块来尝试清理线路。  但无法完全使其正常工作。  如果下拉电阻较弱(100k？) 在几微秒内可能有太多的栅极电容无法放电？

Jason

 

[引用用户="Jason Gossiaux]存在什么值的内部下拉？  数据表似乎没有具体说明它。   [/报价]

内部下拉是弱下拉。 该值介于90K 至120K 之间。  

好的、这将与我们的测量结果相匹配并解释示波器捕获。  我认为 CC2564应该在音频位流完成后将 IO 驱动为低电平、以便与我们其他编解码器的行为相匹配。  让弱下拉缓慢地处理事情对于较高的 BCLK 速率而言是不够的。   

我们正与 ADI 合作、以更好地了解其编解码器的引脚电容、并更好地评估解决此问题所需的尺寸下拉。  但同样、这与我们所面临的噪声问题无关、也不涉及噪声问题。  这只是对可以改进的东西的观察。  他们还在努力复制我们的设置并对 ADAU1772执行进一步的测试。  希望我们能很快了解更多信息。   

谢谢、

 Jason

您好 Jason、

有关此主题的任何新信息？ 如果没有、我将在我们等待您对 ADI 的调查提供更多信息时关闭此主题。 您可以通过发布回复来重新打开主题帖。

此致、
Vihang

Vihang、您好！

 我很讨厌这样一种情况、即我们必须浏览一条不相连的线程、以得出此问题的结论、因此请再给我几天时间、看看 ADI 的位置。  我将附加一些其他波形、这些波形可以进一步深入了解 I2S 时序。   

谢谢、

 Jason

您好 Jason、

不用担心。 在这种情况下、让我们每隔几天发布一次回复、以防止线程锁定。 我将等待您的进一步消息。

此致、
Vihang

我对此表示赞赏。  ADI 工程师为我提供了一些新的配置选项、我将对这些选项进行测试。  这项工作的艰巨部分是不匆忙和直截了当地得出结论。  即将推出更多内容。

谢谢、

Jason

这里的真正挑战似乎是两个音频通道之间对1个 BCLK 延迟的要求。 ADAU1772不能在 CH1和 CH2上支持1 BCLK 延迟、它希望将两组16位数据紧密封装到32 BCLKS 中。 但根据编解码器配置 wiki 页面-

通道2数据输出偏移-帧同步上升和数据启动之间的 PCM 时钟周期数。 注：
请注意、CH2的偏移必须是 CH1数据长度+ 1的最小值。
当不使用 CH2时、此要求也很重要。

根据这一结论、CC2564MODN 在 CH2音频数据之前需要一个 BCLK 延迟。 我是否可以正确读取该值、或者是否可以将偏移设置为等于 CH1的长度并安全地消除该延迟？ 因为当设置为 CH1数据长度+ 1时、我将在我的示波器捕获上获得额外的 BCLK 延迟。

谢谢、

Jason

您好 Jason、

[引述 USER="Jason Gossiaux]从这个结论可以得出 、CC2564MODN 在 CH2音频数据之前需要一个 BCLK 延迟。 我是否正确读取了该延迟、或者是否可以将偏移设置为等于 CH1的长度并安全地删除该延迟？

如果 CH1没有任何 BCLK 延迟(即 CH1的偏移0)、则可以尝试将 CH2偏移设置为 CH1数据长度。 在 VS 命令文档中、我没有找到此注释背后的原因、但此设置值得尝试。

BR、

Vihang

您好 Jason、

感谢您分享您的调查结果。

[引用 user="Jason Gossiaux]]是否可以确认 CH2偏移不需要为+1？  如果是、是否可以更新文档以反映这一点？  这将对使用此器件的未来设计人员大有裨益。   [/报价]

相关文档中可能存在错误。 我在内部提出了这个问题，我们将对其进行审查。 如果不需要偏移1、我们将更新文档以添加校正。

此致、

Vihang

确定此功能后是否可以联系我？  鉴于关闭此主题的紧迫性、似乎不太可能在此处发布响应。

我们的产品将用于可能导致责任问题的工业和安全环境。  比消费产品中的干扰要大得多。  因此、我们有必要准确记录这些基本操作模式。  还需要担心的是、未来的芯片或堆栈版本可能会突然忠实地使用文档并使我们的运输产品变得砖墙。  我们之前就遇到过这种情况、而且在 TI 产品系列中也同样如此。

是否可以通过合同或其他一些安排加快这种确定？  我们面临着两个硬件中的不一致之处、而这些不一致之处是我们自己无法解决的。  即使只是一个时间表也会非常有帮助。  

谢谢、

Jason