[参考译文] TRF7970A：FIFO 溢出

admin

Other Parts Discussed in Thread: TRF7970A, RF430CL331H

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

https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/717839/trf7970a-fifo-overrun

器件型号：TRF7970A
主题中讨论的其他器件： RF430CL331H

大家好、

我偶尔会遇到 TRF79070A FIFO 超限的问题。我希望您能告诉我原因。

此处提供了 TRF7970A 和 STM32L4之间的 SPI 布线(Saleae)

下面是一个屏幕截图：

在3.652+s 时、我们将 FIFO 清空98个字节、但随后对 FIFO 状态寄存器的读取表明存在缓冲区溢出。 FIFO 为128字节、所以我不清楚为什么会发生溢出。

另一个观察结果是、NFC 流量看起来相当稳定、但在3.592+秒时、似乎会放慢速度。我不确定为什么会发生这种情况、我想知道它是否会导致缓冲区溢出。

我们非常感谢您的任何见解！

此致、

Robert Abad

6 年多前

0 admin 6 年多前

TI__Guru**** 1822510 points

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

您好、Robert、

这是一个勘误项 Device#B07、它解释了这一点： www.ti.com/.../sloz011b.pdf

我们建议屏蔽并忽略溢出位、因为它在所有情况下都未正确设置。

0 admin 6 年多前

TI__Guru**** 1822510 points

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

您好、Ralph、

在哪些情况下未正确设置？如何区分正确设置和错误设置？

此致、
Robert Abad

0 admin 6 年多前

TI__Guru**** 1822510 points

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

您好、Robert、

我们从未发现过它的设置逻辑、我们的所有固件示例都完全忽略了该位。只需始终能够及时处理 FIFO 水印中断、从而在 FIFO 数据溢出之前将其读出、即可安全地完成此操作。这样、我们就能够满足所有 NFC 论坛规范、这些规范测试数据传输并通过 TRF7970A 从 RF430CL331H 传输45kB 数据。

0 admin 6 年多前

TI__Guru**** 1822510 points

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

NFC 堆栈已经屏蔽了错误位。那么、在我提供的数据中、FIFO 是否溢出？如果不是、那么这意味着 FIFO 中的数据是从我们的 NFC 标签中的 RF430接收到的数据、对吧？

我在原始帖子中提到的 NFC 交易减速又如何？有什么问题吗？

0 admin 6 年多前

TI__Guru**** 1822510 points

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

您好、Robert、

该文件非常庞大、因此如果您希望我评论某个特定部分、您需要为我提供一些有关确切查找位置的指导。

只要您收到预期的数据量、就不会发生溢出。因此、如果您读取了200个字节、并接收了200个字节、那么您就可以了。这些检查也应在固件中进行、以确保数据包在完全发送或接收后才能完全退出。

就慢而言，通信似乎只是有一些滞后。如果在回复之前需要时间缓冲数据、可能从标签方面。无法100%确定、因为没有 IRQ 线路亮起、以指示读取器是否未及时处理 IRQ。但无论如何、我不会看到任何问题、因为每次读取的数据不会大于 FIFO 大小(小于100字节)、因此即使是从读取器侧读取、也不会因为延迟而丢失任何数据。

0 admin 6 年多前

TI__Guru**** 1822510 points

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

您好、Robert、

在进一步检查逻辑文件后，我没有看到任何与 TRF7970A 的行为不符的地方。是的、溢出位被置位、但是当它从第一个 IRQ 中读出时、FIFO 中只有98个字节、然后、RX 完成中断仅由 FIFO 中剩余的26个字节发出、这些字节已读出、并在0x90 0x00结束、这是读取二进制文件的预期最后字节。请注意、98+26字节也只有124个字节、小于127字节 FIFO、因此无法根据接收到的数据填充 FIFO。

0 admin 6 年多前

TI__Guru**** 1822510 points

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

您好、Ralph、

请允许我后退一步并提供更大的图片。。

我们正在进行 NFC 传输、其中数据有效载荷为300字节：

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

重复执行、直到发送300个字节。

有时、会出现一个断续模式、其中接收到的数据为：

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x07 0x08 0x09

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

0x00 0x03 0x04 0x05 0x06 0x07 0x08 0x09

0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

注意：为了便于阅读、我在这里放置了间距。

发生此错误时、正好与 FIFO 溢出位被置位的位置相同。以绿色突出显示的字节是98字节 FIFO 转储的末尾。 FIFO 溢出、但在下一次读取 FIFO 状态寄存器时被置位。由另一个24字节的 FIFO 读取所产生的折页(以红色突出显示)。我们预计此事务将超过300字节、因此看起来有些数据会丢失。此外、在该24个字节处读取的 FIFO 预期从0x09开始(以继续序列)、而实际接收到的0x07则是如此。 24字节读取的末尾是(0x90 0x00)读取二进制响应的末尾。因此、这两者之间似乎有很多数据丢失。

您提到您无法看到 IRQ 线路的状态。如果我将其包含在 Saleae 文件中、会有帮助吗？

您在上一篇文章中提到、减速(恰好在出现此错误之前)可能与标签相关。您能详细说明一下吗？

此致、

Robert

0 admin 6 年多前

TI__Guru**** 1822510 points

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

您好、Robert、

感谢您分享更多详细信息。我可以清楚地理解、为什么根据您描述的行为对 FIFO 溢出位存在顾虑、而我随后的挖掘在过去几个小时内让我发现了一个兔子洞。我将在这里总结我的所有观察结果。

首先、对于超过300字节的传输、这需要在多个命令之间完成、除非 NFC 堆栈被修改为具有大于256字节的缓冲区。不过、在这种情况下、尝试读取的数据为249字节。有一个小问题、但我认为最好提前澄清、以便我们在同一页上。

其次、您提到的减慢时间、这将是数据传输量的原因。我在发送的文件中没有看到任何其他区域交换了相当数量的数据。因此、"向下"是因为等待无线数据传输的开销。也需要清除它。

好的、现在针对误差本身。首先、当我从纯硬件和低级驱动程序的角度来看待这一点、并回顾 TRF7970A 从 FIFO 长度与数据读出的角度进行通信时、事务似乎正在正常进行。但是、由于我们双方现在都同意我了解数据丢失问题、因此很明显、有些数据不能解决问题。此外、如果数据在无线传输过程中丢失或 TRF7970A 未处理、则会以某种方式出现 CRC 错误、但也不会发生这种情况、因此 A)数据未发送、或 B)数据丢失但未正确报告。

对于 B 点、这会给我们留下 TRF7970A 侧传输的奇数部分-溢出位、它有一个勘误项。现在、阅读勘误表并将其与精确捕获进行比较、引起了另一个好奇心、即勘误表指出、当 FIFO 接收到超过127字节但来自我进行的计算时、可能会设置溢出位、根据 FIFO 状态输出报告的内容、似乎不会出现这种情况。让这种好奇心变得更加复杂的是、通过从内部数据中查看勘误项的详细信息、行为已经在对等模式下显示、但在 TRF7970A 是收发器的情况下不显示 NFC-B。问题更多是 TRF7970A 从另一个收发器接收数据。

从它的外观来看、我们没有遇到与这种确切行为相匹配的情况。

我要说的是，要处理这个问题，可以做两件事之一。

方法1：
让软件验证是否收到请求的数据量、如果没有、请重试事务。我的一部分人认为应该已经发生了这种情况、但我还没有回顾过堆栈中在一段时间内可以处理这种情况的部分。我可能还想使用 P2P、而读取器/写入器的 ISO7816层没有包含该检查。

方法2：
将 TRF79xx 驱动程序修改为：
a)仅屏蔽 P2P 模式下的 FIFO 溢出
b)添加错误处理、当触发 FIFO 溢出时、它会向堆栈报告协议错误。

不过、这两种方法会导致相同的最终结果：重试命令。因此、我建议方法#1、这样 TRF79xx 驱动程序就不需要修改、因为这更复杂、并且有可能导致其他不需要的问题。

但是、未实现方法2的缺点是、如果问题真正与 TRF7970A 侧的器件相关、或者标签未发送足够的数据、则可以尝试并隔离该方法。如果方法#2完全解决了问题、则与 TRF7970A 相关、但如果在溢出位未置位的情况下再次发生错误、然后、它由标签端触发(也可以解释为什么我们以前从未看到过这种行为、因为标签将是导致向下拖至收发器的异常行为的原因)。

从生产层面来看、方法1确实是更安全的选择、但从测试和调试的角度来看、实施方法2并尝试确定哪个器件是行为的根本原因可能是值得的。

请告诉我您对这些调查结果有任何疑问。

0 admin 6 年多前

TI__Guru**** 1822510 points

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

首先、我要感谢您浏览该数据文件。我意识到它很大，不是一项微不足道的任务！！！

是的、我们修改了 NFC 堆栈。现成的实施仅处理 NDEF 短记录。我们对其进行了修改、以便它也可以处理 NDEF 长记录。我们为 NDEF 长记录选择了最大大小1024。我们认为，除了我们看到我们目前正在讨论的这个问题外，这一工作正在正常进行。

我们希望在 TRF7970A 和 STM32L4之间转储 SPI 流量有助于我们确定问题是与读取器还是与标签有关。

您的上一篇文章提到了 CRC 校验。 NFC 堆栈是否对从标签接收到的数据进行 CRC 检查？如果是、您能否指向堆栈中的位置？

0 admin 6 年多前

TI__Guru**** 1822510 points

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

您好、Robert、

CRC 校验在 TRF7970A 硬件内部处理。它会检查 CRC 是否接收到数据。如果传输中发生错误、CRC 校验将失败、IRQ 状态将指示此情况。

其他无线技术（参考译文帖）

其他无线技术（参考译文帖）(Read Only)

[参考译文] TRF7970A：FIFO 溢出