[参考译文] CC2564C：反复出现小音频压降

使用的采样率是多少？ 是44.1K 还是48K？ 您还可以获取 FW 日志吗？

采样率为44.1kHz。

FW 日志到底意味着什么？ 请从固件中找到随附的初始化日志。

在 MSP432P401R 中运行的固件基于 Bluetopia SDK 中的 A3DPDemo_SNK。 主要区别在于、CC2564C 的数字音频接口连接到一个 SPI 端口、而编解码器的数字音频接口连接到另一个 SPI 端口。 捕获的音频数据将通过 DMA 传输到存储器缓冲器(每个 SPI 一个)。 每个存储器缓冲区的大小为16字节、因此它可以精确保存8个16位的音频样本。

此外、我向固件添加了 HFP 支持、这与 TI 的本指南中描述的类似。 但是、由于我在 A3DP 中启动固件、这不应影响用例。 从 A3DP 切换到 HFP 完全不同...

e2e.ti.com/.../startup.log

我是指控制器固件日志。

e2e.ti.com/.../3554.CC256x-Logger-User-Guide-_2D00_-Texas-Instruments-Wiki.pdf

我想附加日志进行配对、开始播放、然后在掉头后停止播放。 但是、上传后表格变为空、我无法附加任何内容。 我尝试附加原始.lgr-file 和封装在7zip 文件中的相同文件-两者都没有成功。

但是、在我向固件添加了压降检测后、我可以与发生压降时控制器固件日志中发生的情况完全匹配：

3131	21:31:47.899   +0:00:21.835	LC Inquiry Scan - Start, LAP=0x9e8b33, Window=9 frames	
3132	21:31:47.899   +0:00:21.835	synch cmd return event STARTED,module INQUIRY SCAN	
3133	21:31:47.899   +0:00:21.835	synch event FINISH received, module INQUIRY SCAN, msi 1	
3134	21:31:47.899   +0:00:21.835	synch cmd start instance, module ACTIVE CONNECTION, msi: 10	
3135	21:31:47.899   +0:00:21.835	synch cmd return event STARTED,module ACTIVE CONNECTION	
3136	21:31:48.273   +0:00:22.209	HCILL send command: HCILL_WAKE_UP_IND_MSG	
3137	21:31:48.273   +0:00:22.209	HCILL state machine is: WAITING FOR WAKE UP ACK	
3138	21:31:48.273   +0:00:22.209	HCILL received command: HCILL_WAKE_UP_ACK_MSG	
3139	21:31:48.273   +0:00:22.209	HCILL release_transmit_queue	
3140	21:31:48.273   +0:00:22.209	HCILL state machine is: AWAKE	
3141	21:31:48.363   +0:00:22.299	HCILL send command: HCILL_GOTO_SLEEP_IND_MSG	
3142	21:31:48.363   +0:00:22.299	HCILL state machine is: WAITING FOR SLEEP ACK	
3143	21:31:48.363   +0:00:22.299	HCILL received command: HCILL_GOTO_SLEEP_ACK_MSG	
3144	21:31:48.363   +0:00:22.299	HCILL state machine is: SLEEP	
3145	21:31:48.408   +0:00:22.344	ACL_DATA_STATISTICS for LC handle 0: Rx bps - 335745 , Tx bps - 14 , remote NACK ratio - 0	

压降已在连接到另一个 COM 端口并启用时间戳记录的串行终端中打印出来。 这里是带有时间戳的文件：

[2021-04-19 21:31:48.252] A3DP+SNK>
[2021-04-19 21:31:48.253] A3DP+SNK>Drop!
[2021-04-19 21:31:51.871] Drop!

稍后、在停止回放之前、我的固件报告了另一个下降。 首先是 HCI 记录器的内容：

7258	21:32:11.544   +0:00:45.480	HCILL send command: HCILL_WAKE_UP_IND_MSG	
7259	21:32:11.544   +0:00:45.480	HCILL state machine is: WAITING FOR WAKE UP ACK	
7260	21:32:11.544   +0:00:45.480	HCILL received command: HCILL_WAKE_UP_ACK_MSG	
7261	21:32:11.544   +0:00:45.480	HCILL release_transmit_queue	
7262	21:32:11.544   +0:00:45.480	HCILL state machine is: AWAKE	
7263	21:32:11.635   +0:00:45.571	HCILL send command: HCILL_GOTO_SLEEP_IND_MSG	
7264	21:32:11.635   +0:00:45.571	HCILL state machine is: WAITING FOR SLEEP ACK	
7265	21:32:11.635   +0:00:45.571	HCILL received command: HCILL_GOTO_SLEEP_ACK_MSG	
7266	21:32:11.635   +0:00:45.571	HCILL state machine is: SLEEP	
7267	21:32:12.010   +0:00:45.946	0x0000BE26	0x0000BE26	HCI_VS_A3DP_Sink_Stop_Stream	---->	
7268	21:32:12.010   +0:00:45.946	0x0000BE27	0x0000BE27	<----	HCI_Command_Complete_VS_A3DP_Sink_Stop_Stream_Event	
7269	21:32:12.011   +0:00:45.947	A3DP SINK: UNDERRUN 1	
7270	21:32:12.011   +0:00:45.947	AVPR received a message from ARM [0x0017], number 23	
7271	21:32:12.011   +0:00:45.947	HCILL send command: HCILL_WAKE_UP_IND_MSG	
7272	21:32:12.011   +0:00:45.947	HCILL state machine is: WAITING FOR WAKE UP ACK	
7273	21:32:12.011   +0:00:45.947	HCILL received command: HCILL_WAKE_UP_ACK_MSG	
7274	21:32:12.011   +0:00:45.947	HCILL release_transmit_queue	
7275	21:32:12.011   +0:00:45.947	HCILL state machine is: AWAKE	
7276	21:32:12.011   +0:00:45.947	hcic_process_hci_commands: HCIPP_A3DP_SNK_STOP_STREAM (Group 3f Opcode 0x19e)	
7277	21:32:12.011   +0:00:45.947	hcic_get_num_of_host_commands. Total free = 3, Reported to host = 1	
7278	21:32:12.011   +0:00:45.947	HCI Send Event: HCI_COMMAND_COMPLETE_EVT	
7279	21:32:12.011   +0:00:45.947	AVPR received a message from ARM A3DP_SNK_STOP_STREAM_COMMAND, number 21	
7280	21:32:12.011   +0:00:45.947	A3DP SINK: stop stream flush_flag 1	

下面是压降消息的时间戳：

[2021-04-19 21:32:11.524] A3DP+SNK>Drop!

真的希望您对此有所了解。

您应该能够上传*。ldr 文件。 否则、请将其重命名为.txt、并将其发送至。

谢谢

e2e.ti.com/.../A3DP_2D00_playing9a.lgr.txt

好的、重命名的技巧似乎起作用了。 对固件中的压降检测做一个注释：由于其性质、与您在 FW 日志中看到的情况相比、这会有一些延迟。 但最大可能延迟为1.5ms (即44.1kHz 时的64个音频样本)、因此应可忽略不计。 下面是上述日志记录期间发生的丢失事件的时间戳：

[2021-04-20 21：21：41.788]快来吧！
[2021-04-20 21：21：55.142]快来吧！
[2021-04-2021:21:55.194]快来吧！
[2021-04-20 21：22：08.511]快来吧！

您能否提供编解码器连接方式的详细信息？ 它需要 I2S 接口、即50%占空比。 您可能需要更正 CC2564C 控制器上的 PCM/编解码器配置、如 HCI_VS_Write_Codec_Config.e2e.ti.com/.../5584.CC256x-VS-HCI-Commands-_2D00_-Texas-Instruments-Wiki.pdf

下面我们转到：这是用于配置 BTmod 音频编解码器的函数：
HRDWCFG_SPI_DIVIDER 的值为8、SMCLK 提供24MHz

static void ConfigureControllerAudioCodec(unsigned int BluetoothStackID, unsigned long SamplingFrequency, unsigned int NumChannels)
{
   Word_t Channel1Offset;
   Word_t Channel2Offset;

   union
   {
      VS_Write_Codec_Config_Params_t          WriteCodecConfigParams;
      VS_Write_Codec_Config_Enhanced_Params_t WriteCodecConfigEnhancedParams;
   } u;

   Channel1Offset = 0;
   Channel2Offset = Channel1Offset + 16;
   BTPS_MemInitialize(&u.WriteCodecConfigParams, 0, sizeof(u.WriteCodecConfigParams));
   // Adjust PCMclock to a value which can be used for SPI transfers:
   u.WriteCodecConfigParams.PCMClockRate_KHz      = CS_getSMCLK() / HRDWCFG_SPI_DIVIDER / 1000;
   u.WriteCodecConfigParams.FrameSyncFrequency_Hz = (DWord_t)SamplingFrequency;
   u.WriteCodecConfigParams.FrameSyncDutyCycle    = 0x0001;
   u.WriteCodecConfigParams.CH1DataOutSize        = 16;
   u.WriteCodecConfigParams.CH1DataOutOffset      = Channel1Offset;
   u.WriteCodecConfigParams.CH1DataInSize         = 16;
   u.WriteCodecConfigParams.CH1DataInOffset       = Channel1Offset;
   u.WriteCodecConfigParams.CH1InEdge             = 1;
   u.WriteCodecConfigParams.CH2DataOutSize        = 16;
   u.WriteCodecConfigParams.CH2DataOutOffset      = Channel2Offset;
   u.WriteCodecConfigParams.CH2DataInSize         = 16;
   u.WriteCodecConfigParams.CH2DataInOffset       = Channel2Offset;
   u.WriteCodecConfigParams.CH2InEdge             = 1;
   VS_Write_Codec_Config(BluetoothStackID, &u.WriteCodecConfigParams);

   /* Set the codec config enhanced parameters.                         */
   BTPS_MemInitialize(&u.WriteCodecConfigEnhancedParams, 0, sizeof(u.WriteCodecConfigEnhancedParams));
   u.WriteCodecConfigEnhancedParams.PCMClockShutdown = 0x01;
   u.WriteCodecConfigEnhancedParams.PCMClockStart  = 0x0000;
   u.WriteCodecConfigEnhancedParams.PCMClockStop   = 0x001F;    // Disable clock after 32 clock cycles
   u.WriteCodecConfigEnhancedParams.CH1DataOutMode = 0x01;
   u.WriteCodecConfigEnhancedParams.CH2DataOutMode = 0x01;
   VS_Write_Codec_Config_Enhanced(BluetoothStackID, &u.WriteCodecConfigEnhancedParams);
}

您是从某些地方获取上述编解码器配置、还是自己执行？ 是哪个编解码器？ 是 TLV320AIC3254吗？ 您是否尝试了 MSP432 BluetopiaSDK A3DPDemo_SNK 示例中提供的编解码器配置？

谢谢

我们目前正忙于其他事情。 几天内回来

谢谢

不清楚为什么要考虑 SPI 位时钟。 您似乎正在将 PCM 时钟配置为3MHz、并将采样频率配置为44.1kHz。 PCM 时钟不是采样频率的整数倍、因此您可能会遇到问题。 尝试使 PCM 时钟成为采样频率的整数倍。 否则、将"FSyncMultiier"配置为32或64。 这使得控制器可以调整 PCM 时钟。  

此外、让 PCM 时钟始终处于激活状态。

谢谢

您非常精确地描述了这种情况：PCM 时钟配置为3MHz、使我能够使用以完全相同的位时钟速度运行的 MSP432P401R SPI 模块捕获音频样本。 我没有发现 MSP432P401R 支持的任何 SPI 时钟 与44.1kHz 的多个采样频率相匹配。

由于 SPI 的性质、我无法始终保持 PCM 时钟处于活动状态-因此、我必须在传输左通道和右通道后丢弃 SPI 模块读取的虚拟样本(希望名称有意义)。

应在何处/如何配置 FSyncMultiplier？这实际上意味着什么？

恐怕我开始理解：PCM 时钟出现在/ha//t//be/是采样频率的整数倍、对吧？

是否有机会使用 MSP432P401R 从 BTmod 捕获音频？ 我的意思是、尽管(以某种方式)周期性音频下降或(就像我现在所说的)同步问题、我的当前配置仍在工作。

我不熟悉您的设置和 SPI 的需求。 任何方式、如果 CC2564x VS 命令、则连接。 我认为您无法在 MSP432上捕获音频。

e2e.ti.com/.../3718.CC256x-VS-HCI-Commands-_2D00_-Texas-Instruments-Wiki.pdf

谢谢

简短更新：我已经能够捕获音频；在发生上述 CC2564C 的错误行为之前、它将工作几秒钟。 此外、我在 MSP432P401R 固件中管理、以便在 CC2564C 提供的 framesync 信号上再次同步。 唉，这个过程对用户来说是/heartable/，任何人都不会接受最终产品中的这个过程。

Hari Nagalla、我将在此向您展示我在此主题中设置的组件图。 如果您有兴趣、我还可以在 PM 之前向您发送马戏团图。

下面是(简化的)组件图-请删除文本扩展名以查看 SVG。

e2e.ti.com/.../CompDiagram.svg.txt

您可以发送 pdf 版本的图表吗？  

是的、我可以：

e2e.ti.com/.../CompDiagram.pdf

我现在看到了图。。。 为什么 CC2564C 无法直接连接到 MAX9867编解码器？ 在 MSP432上进行何种信号处理？  

我建议先尝试演示中提供的默认配置。

谢谢

感谢您分享您的想法。

在我们的设置中、只有一个音频编解码器用于录制+播放。 但是、我们打算使用不同的播放源。 一个是 BT 模块、另一个是 μ µC 的外部存储器。 由于我们无法将这些不同的源连接到单个编解码器、因此我们仅将 MSP 连接到 Max9867。 因此，我们需要使它发挥作用。

此外、该问题在 MSP432之外出现-如上面的逻辑分析仪所示。 在早期开发阶段、我们成功测试了 CC2564C 和 Max9867之间的直接连接。 但是、在这种情况下、CC2564C 内的编解码器以不同的方式进行配置-与上述规格相匹配(PCM 时钟是采样频率的倍数、PCM 时钟始终处于激活状态)。

我看到.. 让我在几天内回来..

谢谢

IMO、当您像这样路由 PCM 时、您需要在 MSP432上进行速率调整、因为在一侧它充当 PCM 从设备、而在另一侧充当 PCM 主设备。 您是否考虑将 CC2564C 用作主器件与连接到 MSP432和 Max9867编解码器的相同 PCM 总线？ 当然、CC2564C 和 MSP432的"音频输出"需要一个开关来选择 Max 9867编解码器。  

在这种情况下、您可以从 CC2564C 一直保持 PCM 位时钟和 FSYNC 处于激活状态。

谢谢

感谢您回到本主题。

您描述为替代解决方案的设置与我们的概念验证硬件类似： 在 Max9867编解码器(以及 Fsync、bitclock)上、已经有一个将"BTmod 中的"Audio Out"快捷方式切换到"Audio in"的开关、它完全按照您所描述的方式工作、无需 MSP432进行进一步交互。 但是、这是一个 A 样本硬件、对于最终产品、甚至必须/不/这样的连接是可能的。

MSP432上的"速率自适应"背后的含义是什么？如何实现这些目标？ 是的、朝向 CC2564C、控制器是 PCM 从控制器、对于 Max9867编解码器、控制器是 PCM 主控制器。 是否可以使 CC2564C 也用作 PCM 从设备-这是否可以解决问题？

我的意思是、在两条 PCM 总线上连接时、可能会有不同的 PCM 时钟漂移。 这可能会导致采样随时间的推移而欠载或溢出。 通过速率调整、我打算 补偿 PCM I/FS 上的这些漂移。 PCM 位时钟速率是否与 CC2564C 和 Max9867编解码器相同？

您还可以尝试将 CC2564C 配置为从器件。

谢谢

我已经将漂移确定为一个问题。 下面是我解决此问题的方法：

1. 通过 P2.4中断对来自 CC2564C 的帧同步信号进行同步捕捉。
2. 启动具有 DMA 的 SPI 以向 Max9867发送16字节(即左通道4个样本、右通道4个样本)、由 Timer_A3触发、并具有与采样频率匹配的适当周期。
   此外、Timer_A3_CCR2将触发 P8.2以提供 Max9867的 LRCLK 信号。
3. 开始使用 EUSCI_B2连续从 CC2564C 捕获音频样本。 捕获由 DMA 完成：复制16个字节、然后 DMA 完成中断发生。
   重要提示：禁用 framesync 中断。
4. DMA 完成后：
   启用 framesync 中断
   重新启动 DMA 通道以在下一帧同步边沿上继续捕捉(步骤3)。
5. 在发生 framesync 中断时：
   明确地设置 Timer_A3的计数器值、在某个值上控制 DMA 向 Max9867的传输(此时由断点命中检查)。 这样就消除了 Fsync 到 Maxim 和 Fsync 到 CC2564C 之间的任何可能漂移。

已选择 Timer_A3的起始点、其在帧同步中断期间永远不会过期。 此外、通过检查此时(通过 DMA)向 Max9867传输了多少字节、我可以检测到此线程的第一个帖子中描述的情况、并从头开始重新启动同步过程。

我无法了解如何将 CC2564C 音频接口作为从设备运行-如何实现/配置此操作？

忘记提到一个要点：第一个 DMA 传输到 Max9867的大小只有一半-这样一来、当来自 CC2564的 framesync 信号到达时、下一个传输应该/完全/半向完成。 如果没有出现问题、我们需要再次重新同步。

我不是 MSP432 DMA 架构的专家、因此请访问该论坛。 如前所述、您还可以尝试将 MSP432用作两条 PCM 总线的 PCM 主站。 请参阅 用于 STM32的 CC2564CBT 协议栈的 A3DP Demo_snk 样片。 在此示例中、STM32F4 MCU 是 PCM 主设备。

https://www.ti.com/tool/CC2564CSTBTBLESW

谢谢

您是否曾尝试将 MSP432用作两个连接的 PCM 主设备？ 如果有问题、请提出新的问题。 我将关闭这个。

谢谢

Hari Nagalla、再次感谢您关注此问题并提供您的想法！

最后、我将 CC2564C 数字音频接口作为从器件运行(因为我可以使用 MSP432中的端口映射器交换 SIMO/SOMI 引脚-很好的功能)。 我甚至能够从 FSYNC 脉冲切换到 LRCLK 信号、音频最终变为耳戴式。

遗憾的是、短暂的干扰仍然是一样的！ 只有逻辑分析仪的外观不同。 它们以不规则的间隔出现。 我将按照您的建议提出新的问题。