[参考译文] TM4C129ENCPDT：带有 SSI 的 UDMA 在接收时有时会延迟32位(4字节)

您好 Brian、

我花了一些时间来研究这一点、但我无法发现任何能够解释这种行为的东西。 此时、我想我能做的最有用的事情是查看您代码的相关部分、了解您的情况：

配置 SPI/UDMA

写入 SPI 闪存

在发生不良状态时、正在执行何种复位操作来尝试和解决该问题。

我要问的另一个问题是、当出现额外的字时、它是完全非感应数据、还是有任何迹象表明它与之前的事务或之前加载到 UDMA 中的数据相关？

您好 Brian、

此外、您使用的是什么时钟源？ 请确保勘误项 SSI#04不适用于此操作。

[引用 USER="Ralph Jacobi">此时我想我能做的最有用的事情是查看代码的相关部分、了解您的情况：

配置 SPI/UDMA

SSI：

MAP_SysCtlPeripheralEnable (SYSCTL_Periph_SSI0)；
MAP_SysCtlPeripheralEnable (SYSCTL_Periph_GPIOA)；
MAP_GPIOPinConfigure (GPIO_PA2_SSI0CLK)；
// FSS 的软件控制需要跳过 GPIO_PA3_SSI0FSS
//对于 FSS 的硬件控制，取消注释此行
// GPIOPinConfigure (GPIO_PA3_SSI0FSS)；
MAP_GPIOPinConfigure (GPIO_PA4_SSI0XDAT0)；
MAP_GPIOPinConfigure (GPIO_PA5_SSI0XDAT1)；
MAP_GPIOPinTypeSSI (SSI0_BASE、GPIO_PIN_2 | GPIO_PIN_4 | GPIO_PIN_5)；
MAP_GPIOPinTypeGPIOOutput (SSI0_BASE、GPIO_PIN_3)；
HWREG (SSI0_BASE + SSI_O_CR1)= SSI_CR1_MS | SSI_CR1_SSE | SSI_ADV_MODE_READ_WRITE；
HWREG (SSI0_BASE + SSI_O_CPSR)= 2；
HWREG (SSI0_BASE + SSI_O_CR0)= 0x0307；

uDMA：

MAP_SysCtlPeripheralEnable (SYSCTL_Periph_UDMA)；
MAP_SysCtlPeripheralSlepEnable (SYSCTL_Periph_UDMA)；
map_uDMAEnable()；
MAP_uDMAControlBaseSet (UDMA_CONTROL_TABLE)；
//开始事务：
ROM_uDMAChannelAttributeDisable (UDMA_CHANGE_SSI0RX、UDMA_ATTR_ALTSELECT | UDMA_ATTR_HIGH_PRIORY | UDMA_ATTR_REQMASK)；
ROM_uDMAChannelAttributeEnable (UDMA_CHANGE_SSI0RX、UDMA_ATTR_USEBURST)；
ROM_uDMAChannelControlSet (UDMA_CHANNEL_SSI0RX | UDMA_PRI_SELECT、UDMA_SIZE_8 | UDMA_SRC_INC_NONE | UDMA_DST_INC_8 | UDMA_ARB_4)；
ROM_uDMAChannelTransferSet (UDMA_CHANGE_SSI0RX | UDMA_PRI_SELECT、UDMA_MODE_PINGONG、SSI0_BASE + SSI_O_DR、dstPri、SIZE)；
ROM_uDMAChannelControlSet (UDMA_CHANNEL_SSI0RX | UDMA_ALT_SELECT、UDMA_SIZE_8 | UDMA_SRC_INC_NONE | UDMA_DST_INC_8 | UDMA_ARB_4)；
ROM_uDMAChannelTransferSet (UDMA_CHANGE_SSI0RX | UDMA_ALT_SELECT、UDMA_MODE_PINGONG、SSI0_BASE + SSI_O_DR、dstAlt、SIZE)；
ROM_uDMAChannelEnable (UDMA_CHANGE_SSI0RX)；
ROM_uDMAChannelAttributeDisable (UDMA_CHANGE_SSI0TX、UDMA_ATTR_ALTSELECT | UDMA_ATTR_HIGH_PRIORY | UDMA_ATTR_REQMASK)；
ROM_uDMAChannelAttributeEnable (UDMA_CHANGE_SSI0TX、UDMA_ATTR_USEBURST)；
ROM_uDMAChannelControlSet (UDMA_CHANNEL_SSI0TX | UDMA_PRI_SELECT、UDMA_SIZE_8 | UDMA_SRC_INC_8 | UDMA_DST_INC_NONE | UDMA_ARB_4)；
ROM_uDMAChannelTransferSet (UDMA_CHANGE_SSI0TX | UDMA_PRI_SELECT、UDMA_MODE_PINGONG、srcPri、SSI0_BASE + SSI_O_DR、SIZE)；
ROM_uDMAChannelControlSet (UDMA_CHANNEL_SSI0TX | UDMA_ALT_SELECT、UDMA_SIZE_8 | UDMA_SRC_INC_8 | UDMA_DST_INC_NONE | UDMA_ARB_4)；
ROM_uDMAChannelTransferSet (UDMA_CHANGE_SSI0TX | UDMA_ALT_SELECT、UDMA_MODE_PINGONG、srcAlt、SSI0_BASE + SSI_O_DR、SIZE)；
ROM_uDMAChannelEnable (UDMA_CHANGE_SSI0TX)；
ROM_SSIIntEnable (SSI0_BASE、SSI_DMATX | SSI_DMARX)；
ROM_IntEnable (INT_SSI0)；

[引用]写入 SPI 闪存[/引用]

MAP_SSIAdvModeSet (SSI0_BASE、SSI_ADV_MODE_READ_WRITE)；
_select (nPort)；
//在标准 SPI 模式下发送命令字节(实际上是高级 R/W)
MAP_SSIDataPut (SSI0_BASE、COMMAND_2READ)；
MAP_SSIDataGet (SSI0_BASE、\ui32)；
MAP_SSIDataPut (SSI0_BASE、地址>> 24)；
MAP_SSIDataGet (SSI0_BASE、\ui32)；
MAP_SSIDataPut (SSI0_BASE、地址>> 16)；
MAP_SSIDataPut (SSI0_BASE、地址>> 8)；
MAP_SSIDataPut (SSI0_BASE、地址)；
// SIO1和 SIO0上的8位数据虚拟周期 a.k.a. 4添加周期
MAP_SSIDataPut (SSI0_BASE、0x00)；
对于(I = 0；I < 4；I++)
MAP_SSIDataGet (SSI0_BASE、\ui32)；
while (MAP_SSIBusy (SSI0_BASE))
；
MAP_SSIAdvModeSet (SSI0_BASE、SSI_ADV_MODE_BI_READ)；
while (HWREG (SSI0_BASE + SSI_O_SR)& SSI_SR_BSY)
；
//确保读取 FIFO 为空
while (HWREG (SSI0_BASE + SSI_O_SR)& SSI_SR_RNE)
数据= HWREG (SSI0_BASE + SSI_O_DR)；
//参见上面的 UDMA"开始事务"

[引用]在发生错误状态时、正在执行何种重置操作来尝试和解决该问题。

到目前为止、只有 CCS 中"Reset"图标下的"System Reset"菜单项看起来可以正常工作。 我已经寻找了一些其他方法来重置 UDMA、但尚未找到它。 等待 SSI 忙线使 Rx FIFO 失效和清空 Rx FIFO 的所有方式似乎对 UDMA 没有影响。 在每次交易之前、我想整体重置 uDMA 外设、但它可能会被其他外设使用、因此我甚至没有尝试重锤。

[引用]我会遇到的另一个问题是、当额外的字出现时、它是完全非感应数据、还是有迹象表明它与之前的事务或之前加载到 UDMA 中的数据有关？

有一种模式、即当问题首次出现时、额外的字是一个值。 之后、额外的字在第二个事务上具有不同的值、然后在后续每次重复时保持不变。 这似乎表示 SSI 或 SSI Rx FIFO 有一些来自之前事务的陈旧数据、但我有代码在启动 UDMA 之前清除 Rx FIFO、因此我不知道会留下什么陈旧数据。

另请注意、在触发错误之前、读取 SPI 闪存的 UDMA 事务可以重复多次、而不会有任何过时的数据。 即、第一个字是正确的、所有后续字也是正确的。 不过、在触发错误后、无论有多少个 PIO 与 DMA 存取交错、都会始终存在额外的字(直到系统复位)。 此外、请注意、即使在错误触发后与 UDMA 事务交错、对 SPI 闪存(无 UDMA)的 PIO 访问始终是成功的。 出现问题后、似乎什么也不能解决、在同一 SSI 端口上的 PIO 传输甚至不成功！

注意：我已将许多子例程连接到上面的线性代码流中、因此可能会出现轻微错误。 您看到的冗余忙等待出现在那里、因为它出现在一个函数中、然后调用另一个也有等待的子例程。

不使用 ALTCLK。 该代码使用系统时钟、因为我们需要60MHz 或至少15MHz 的速率。 我认为 ALTCLK 不能超过16MHz。

您好 Brian、

查看您的 SSI 配置、我认为您可能缺少一些参数、因为您没有使用建议的 TivaWare API。 具体而言、我看不到可确保设置正确模式和数据大小的设置。 请注意、对于高级模式、您必须根据以下条件使用 Motorola Mode 0：

//！ 当使用一个高级运行模式时、SSI 模块必须已经//
！ 配置为八个数据位和\b SSI_FRF_MOTO_MODE_0协议。
//！ 所选的高级模式操作仅适用于新数据
//！ 写入 FIFO；FIFO 中已存在的数据为
//！ 当数据为
//时、使用有效的高级操作模式进行处理！ 书面。 

除此之外、我遇到的另一个提供一些线索或想法的问题是勘误表、它听起来与您的情况不匹配、但您可以查看并比较您的系统的行为、即  www.ti.com/.../spmz850g.pdf 上的 SSI#05

[引用 USER="Ralph Jacobi">浏览您的 SSI 配置、我认为您可能缺少一些参数、因为您没有使用推荐的 TivaWare API。 具体而言、我看不到可确保设置正确模式和数据大小的设置。 请注意、对于高级模式、您必须使用 Motorola Mode 0

感谢您的评论、Ralph。 请注意、SSI 配置的最后一行是：

HWREG (SSI0_BASE + SSI_O_CR0)= 0x0307； 

(笑声) 在所有情况下都应强制 FRF=0x0 (Freescale SPI)和 DSS=7 (8位数据)。

是否有其他先决条件？

另请注意、在写入 SPI 闪存之前、先进行 SSI 配置。 因此、在外设已处于 Motorola 模式0后、会调用 SSIAdvModeSet (SSI_base、SSI_ADV_MODE_BI_READ)。

[引用 USER="Ralph Jacobi]]我遇到的另一个提供一些线索或想法的问题是勘误表、它听起来与您的案例不匹配、但您可能可以查看并比较您的系统的行为、即  www.ti.com/.../spmz850g.pdf上的 SSI#05

你是对的-我认为 SSI#05不适用。 无论我使用双模 SSI 还是常规1位高级模式、都会出现此问题。

新信息：

我在一段时间内没有运行1位读取测试、因此我编码了一个测试用例并发现了一些新的行为。 当使用纯1位 SPI 闪存命令(和数据)时、这个问题出现在一个长链读取的中间、而没有任何其他(不相关)命令。

背景：

当运行配置代码如上所示的双模式测试时、大约64 MB 的数据会被完美读取(在系统复位后)。 由于 TM4C129E SRAM 仅为256KB、因此 UDMA 将每条命令写入仅16KB (0x004000)、然后循环以在下一个地址继续。 此测试无误地重复4、000次以上(非 DMA 命令和地址阶段后跟 UDMA 数据阶段)。 我连续重复该命令五次、并且始终成功。

新的1位读取测试基本相同、在16 KB 块大小的命令中从 SPI 闪存读取大约64 MB 的数据。 第一个运行在块数1、411的开头显示了缺少的字。 随后的运行在数字为289的块开头显示了缺少的字。 伪波字是第一次为0xBFBFBFBF、第二次为0x3F3F3F。

我不确定这是什么、但现在我知道它与触发双模错误的非 DMA 擦除/程序命令无关。 1位模式读取将在环路中间触发此问题。 因此、每次循环迭代写入 SSI 的数据几乎完全相同、不同之处在于 SPI 存储器地址会针对循环的每次重复递增16 KB。 我看不到这会如何触发错误、因为在双模式下访问相同的地址。

感谢您继续研究这一问题。

一些其他信息：

我已将 FIFO 设置为处理32位数据块(突发)、并仔细编写固件以确保 uDMA 传输大小始终是4字节的倍数。 任何与 SSI 外设的非 UDMA 传输都将通过等待 BUSY 位清零、并在开启 UDMA 前确保接收 FIFO 为空来清零。 这应该保证所有的 UDMA 传输都涉及一整数个32位字。

也就是说、当我关闭突发时、我的代码停止工作。 我没有找到相关的解释、因此我重新打开了它、既是为了让事情正常工作、也是为了提高性能。 我仍然担心32位异常在某种程度上与突发模式有关。

在这方面、我不确定当数据大小不是4个字节的倍数时、在突发模式下会出现什么预期行为。 是否会传递额外的字词？ (笑声) 还是奇数数据只会在添加额外数据之前一直保留在 FIFO 中？ 也就是说、我不认为我看到的症状可能是由于滥用突发模式所致、但我想提及这种可能性。

您好 Brian、

我需要与一位同事谈论此 DMA 问题以及您发布的另一个问题、但直到下周周三才能解决。

感谢您的状态更新。

供参考：多家芯片供应商- Macronix 和 Micron -以及不同尺寸(128 MB 和1 GB)都再次出现了这些问题。

您好 Brian、
我建议您将 RX FIFO 清空置于例程开始写入闪存的位置、而不是末尾 这就是为什么：在写入闪存的例程中，您在每个 SSIDataPUT()之后跟随一个 SSIDataGet ()。 六个压点和六个压点。 如果 RX FIFO 开始为空、那么它在末尾应该为空。 假设在写入闪存的例程开始时 RX FIFO 中有4个字节。 最后需要刷新4个字节 但是、由于 TX FIFO 以及开始发送和完成接收之间的延迟、可能会在最后四个字节完成发送之前对接收为空进行测试。

[引用 user="Bob Crosby">我建议您在例程开始时将 RX FIFO 清空、以写入闪存、而不是写入末尾 这就是为什么：在写入闪存的例程中，您在每个 SSIDataPUT()之后跟随一个 SSIDataGet ()。 六个压点和六个压点。 如果 RX FIFO 开始为空、那么它在末尾应该为空。 假设在写入闪存的例程开始时 RX FIFO 中有4个字节。 最后需要刷新4个字节 但是、由于 TX FIFO 以及开始发送和完成接收之间的延迟、在最后四个字节完成传输之前可能会对接收空进行测试。[/QUERP]

感谢 Bob 的建议。 我相信我的代码已经在例程开始的_select()函数中处理了这个。

静态内联 void _select (unsigned nPort)
｛
SPI_xfer_flush_Rx (nPort)；
MAP_GPIOPinWrite (g_SSi[nPort].port_base、g_SSi[nPort].fss_pin、0)；
｝
SPI_xfer_error_t SPI_xfer_flush_Rx (无符号 nPort)
｛
uint32_t ui32DataRx；

IF (nPort >= SSI_ports)
返回 kSPIXferErrorInvalidIndex；
while (MAP_SSIDataGetNonBlocking (g_SSI[nPort].SSI_BASE、&ui32DataRx))
；
返回 kSPIXferErrorNone；
} 

这可确保在 SPI 闪存存储器芯片选择被置为有效前、任一 FIFO 中没有数据保持。

您好 Brian、

老实说、目前我们很难衡量出出现了什么问题、因为我们手头没有类似的设置。 不过、简化事情可能有助于发现故障点。

要开始简化、您是否可以改用传统模式？ 我们并不是很熟悉 UDMA +高级模式、而是以前真正为我们介绍过。

此外、您还提到了使用 MCU 将命令发送到 SPI 闪存、但也有用于 UDMA 的 TX 代码。 可能会触发某个操作、因此现在最好注释掉 UDMA 的 TX 代码。

如果在执行这些步骤后问题仍然存在、我们可以使用简化的设置尝试一些调试想法。

目前，这个问题和其他问题都有相当好的机会，因此，让我们一次处理这些问题。 如果您看到损坏的位行为在某个时候消失、请注意这一点。

[引用 user="Ralph Jacobi">简化内容可能有助于发现故障点。

要开始简化、您是否可以改用传统模式？ 我们对 UDMA +高级模式并不是很熟悉、以前也不是很熟悉。
我可以尝试使用传统模式。
[引用 USER="Ralph Jacobi">您还提到您使用 MCU 将命令发送到 SPI 闪存、但您也有用于 UDMA 的 TX 代码。 可能会触发某个操作、因此现在注释掉 UDMA 的 TX 代码将会更好。

我有用于删除 UDMA 的所有 Tx 代码的编译器指令。 即使所有 Tx 代码都是 PIO (非 DMA)、RX UDMA 问题仍然会发生。

您好 Brian、

是否有幸尝试使用传统模式？

[报价用户="Ralph Jacobi"]尝试使用传统模式是否成功？[/quot]

感谢您的跟进。

不，我没有运气。 传统模式产生的错误与我之前看到的完全相同。

是否有任何尝试找到具有 UDMA + SSI 体验的人员的进度？ 我觉得我正在探索全新的领域。
在该注释中、是否有任何使用 UDMA 读取和/或写入 SPI 存储器的示例？ 这可能是一个良好的开端。 如果我可以运行这些演示、那么我可能能够查看我是在做什么不同、还是错过了一个步骤。

Brian、我使用 SSI2和 UDMA 独立创建了一个项目。 我没有遇到你提到的任何问题。 您可以查看该示例、看看是否存在可能会导致您所看到行为的差异。

/cfs-file/__key/communityserver-discussions-components-files/908/2318.udma_2D00_ssi2_5F00_demo.zip

版本、使用缓冲 UARTprintf 来避免丢失某些传输的验证。 将 PD0连接到 PD1、以便 SSI2接收其传输的内容。

/cfs-file/__key/communityserver-discussions-components-files/908/7462.udma_2D00_ssi2_5F00_demo.zip

谢谢、Bob。

您的代码对我来说运行正常、但它不执行等效的 SPI 存储器命令(其中非 uDMA 和 uDMA 传输发生在彼此之间)。 换句话说、您的示例代码可能太简单、无法触发我看到的问题。

正如我提到过的、我的代码在系统复位后立即经历了正确的 SSI/uDMA 数据对齐、只要我想不出错、我就可以重复某些基于 uDMA 的命令。 但是、某些 SPI 命令序列(可能是奇数个字节)会触发32位未对齐问题、该问题会一直存在、直到下次系统复位。

我还没有找到确切的触发器-有多个触发器-我还没有找到任何比系统复位更不严格的方法来恢复 SSI FIFO 和 UDMA 外设之间的对齐。

是否可以扩展这个基于回送的 SSI+FIFO+UDMA 示例代码、以便它使用实际的外部存储器芯片执行完整的 SPI 命令？

我怀疑、我们在这里看到的问题将会暴露在非 uDMA 和 uDMA 传输更复杂的交错中。

我看到 TM4C129X 开发板具有某种 SPI 存储器芯片。 它的连接与我们的某个固件外设分配冲突、因此我很难在那里运行我们的代码。 是否有可能扩展这个德州仪器示例代码来与 TM4C129X 电路板上的 SPI 芯片通信？ 只需检查 SPI 芯片状态、然后执行较长的 UDMA 读取和/或写入命令、将非 UDMA 用于 SPI 命令和地址阶段、将 UDMA 用于数据阶段即可。

好消息是、我看到示例代码设置了一次外设、并且在测试迭代之间不会重置任何外设。 这至少与我们的固件类似、在固件中只执行一次设置、所有操作都将一直运行、直到启动某些交互式命令序列。 我怀疑可能有一个外设状态需要复位。 如果我当前为恢复功能而执行的完全系统复位没有达到要求、将会有所帮助、因为当多个外设同时处于活动状态时、显然无法复位整个芯片。

您好 Brian、

Bob 和我讨论了您的请求、但将该示例扩展到该级别所需的工作量很大、因此该请求超出了我们可以提供的范围。

如果怀疑非 uDMA 和 uDMA 传输的交错是根本原因、 然后、找出问题的最佳方法是尝试并简化该过程、以确定在配置或应用程序级处理中发生这些命令传递的步骤似乎是问题的触发因素。 另一个想法是、也只使用 UDMA 命令来验证它是否是交错(如果我记住、您已经验证了只有非 UDMA 工作)。

在简化过程时、也许您可以根据提供的示例进行操作、从而在此过程中在 TI EVM 上重现此问题、这将是我们深入探讨此问题的最快方法。

总的来说、这些以前未出现的非常具体的问题确实需要将问题简化到我们可以深入了解触发问题的 API 或操作序列的程度、以便我们可以进行进一步的分析、从而了解出了什么问题 并尝试解决它。