[参考译文] CC3235SF：将数据映射到内部闪存时、通过 I2S 播放声音数据时出现问题

您好、Siegfried、

不可以、DMA 外设应该能够从内部闪存连接到 I2S 外设。 使用 i2sParams->fixedBufferLength =400进行的测试显示了这种情况。

您是否仔细检查了 const 以及传递给 DMA 传输函数的实际存储器地址、以确保当 fixedBufferLength = 512时、内部闪存被正确访问、即缓冲区中没有某种中断？ 此外、您能否检查是否没有任何其他可能导致故障的不相关 RTOS 损坏或堆栈问题？

在故障情况下、您还可以使用调试器还是打印出 DMA 控制表寄存器？ 这将向我们显示 DMA 传输的状态、并让我们看看可能导致您的问题的原因。

此致、

Michael

您好、Michael、

它可以绝对再现。 始终使用相同的数据缓冲区、只需在  fixedBufferLength = 512和400之间切换即可。  

这种情况在两种设置中都发生、但很少发生400个字节、并且经常发生512个字节、对我来说唯一的区别是任意大小为8或16字节。  

const 数组完全定义为短数组。 我还尝试了其他对齐选项或类似的东西、但没有什么帮助。

始终有效的基地址和列表地址。 仅回写函数不再像列表变空或 DMA 传输的 IRQ 丢失一样被调用。
对我来说、它似乎基于仲裁数目。 我不理解的是、没有调用任何错误处理程序。 传输在无暂停长度后结束。 堆栈损坏可以排除在接近100%的范围内。 传输速率仅为8kHz、每个样本包含两个字节。

大多数情况下、问题发生的时间是并行进行 OTA 更新任务执行一些传输。  
当并行访问外部闪存文件系统时，问题尤其会出现。  
如何查看/调试 DMA 控制寄存器？ 未调用错误处理程序。 我只是看到并非所有数据都在传输。  

但这仅在超时后清除。  

其他可能相关的信息、当我使用基于覆铜 RAM 的数据缓冲器时、两种传输模式都能正常工作。

感谢您的反馈、如果有机会、我将为您提供必要的信息。  

此致

Siegfried

您好、Siegfried、

感谢您提供澄清信息。

如果您怀疑仲裁数目可能是问题的原因、那么我们可以对其进行调整、看看它是否可以修复问题。 如果您看一下 SDK 的 source/ti/drivers/I2S/中的 I2SCC32XX.c 文件，在 initObject()中，驱动程序将根据缓冲区长度设置 DMA 仲裁大小。 此设置尝试查找可能的最大仲裁大小以进行优化、但您可以修改该大小以指定固定的仲裁长度。 如果将 udmaArbLength 设置为固定的4或8字节设置、是否会导致任何更改？

如果没有、那么在错误发生时查看 DMA 控制寄存器的状态将很有用。 DMA 控制表位于 dmaControlTable 存储器地址、您可以使用.map 文件来查找已编译二进制文件的存储器位置。 然后、一旦您拥有 dmaControlTable 的存储器内容、您就可以根据 TRM 第4节中的信息来引用该内容、以便查看 DMA 传输的当前状态。

www.ti.com/lit/swru465

此致、

Michael

您好、Michael、

感谢您的快速回复、我们将查看此文档、但仅在我度假之后。

我在接下来的两周内都不在办公室。

此致

Siegfried

您好、Siegfried、

感谢您的通知、请在您有机会查看该文档并执行 DMA 仲裁测试后回复并更新此主题。

此致、

Michael

您好、Michael、

今天的时间。 注释后、DMA 控制表在两种情况下看起来都很好、值正确。  

这意味着当崩溃时、它会停止在可疑的点、但不会达到预期的终点 但它进行了一些传输。
但绝对可以重现的是、当 DMA 仲裁器长度为16时、它会崩溃。 当它被设置为8时、它就会工作。  

但即使在8Bytes 突发时、我每次都将 I2S 速度加倍、达到16kHz、而不是8kHz。  

因此、对我来说、它看起来完全不能从内部闪存中正常工作。
感谢您的评论。

此致  

Siegfried

您好、Siegfried、

您需要注意的是、即使在8字节仲裁中、I2S 速度加倍和比特率增加也会导致相同的问题。 因此、内部闪存上似乎存在一些瓶颈、这会导致您的问题。

我将仔细查看并查看我是否可以找到有关内部闪存+ DMA 是否存在访问速度/延迟/吞吐量瓶颈的信息。 我模糊地记得，几年前，我的一位同事在这个问题上做了一些实验，所以我将询问并查看数据是否仍然可以访问。 我将在本周结束时向您介绍搜索结果。

此致、

Michael