[参考译文] TRF7970A：发送到 MSP430且被 CRC 覆盖的最后一个字节

尊敬的 Charles：

我发现问题出现在第一个读取周期和重复尝试时、间歇性地出现。  在执行16插槽资源清册时、我还在每个插槽中至少看到过一次此问题。

发出软初始化命令、确认寄存器0x18初始化为0x00。  我参考了 SLOC300、该器件可以在多个电路板上正常工作、

您好、

Unknown 说：

我引用了 SLOC300、其中固件在多个电路板上都可以正常运行、而不会出现问题。

 SLOC300是  TRF7970AEVM 的固件、已停产、但其上使用的固件非常过时、存在从未解决的已知错误。 话虽如此、我很好奇您提到 SLOC300、您的自定义固件和 SLOC300之间的细微差异不会出现问题。  

为确保成功、请使用最新的 RFID 读写器固件(www.ti.com/.../sloc297)作为您的设计参考。  

您好 Charels、

我们努力使 SLOC297固件在我们的系统上运行、由此耽误了很长时间、对此我深表歉意。  我们已经过测试、但 SLOC297仍会出现相同的问题。  当时、我们进行了额外的测试并进行了其他几项观察。  如下图所示、我们确定了通过在 TX 确认后添加延迟、可以暂时解决该问题。  然而,延迟的长度有一个奇怪的影响。  使用无操作而不是基于计时器的延迟、我们发现该问题在注入无操作的数量下保持稳定的周期性。  例如、200 no-ops 显示该问题、而400 no-ops 清除该问题。  遗憾的是、如果一个标签上没有出现问题、选择延迟将不起作用、因为其他标签显示类似的模式、但"波形"会发生偏移。  没有"一刀切"。

我们还尝试了其他硬件、包括我们的晶体振荡器和电容器、但无济于事。  然而、在弯曲电路板时观察到了一种有趣的效果。  向下按压电路板时、弯曲电路板可显著增加故障、而从底部向上按电路板可显著减少故障。  另外、使用塑料镊子轻轻地对 TRF IC 的两侧施加压力也可以看到这一点。  这使我们相信这是一个硬件问题。  我们验证了焊接和电路板走线均良好。

这些数据是否指向任何已知问题？  我们已查看勘误表文档、但找不到任何明显的解决方案来解决此问题。

您好 Brenden、

您是否始终使用 SOFT_IN 启动读取周期？ 除其他外、软初始化用于复位器件上的状态机。 TI 建议从每个读取周期开始、首先执行软初始化、以确保器件中的所有状态机都刷新、并且器件保持已知的良好状态。  

是的、我们已经在每个读取周期之前尝试执行 soft init、但最后一个字节仍然遇到错误。  

您好 Brendon、

 简单来说、您能回答几个问题吗？

-你现在谈论的最后一个字节仍然是 UID 或标签的其他块? 在您的原始线程描述中、UID 是已损坏的。  

-在您的原始描述中,您能够使用两种方法解决问题"出现解决该问题的两种方法是取消天线/信号的调谐(通过在磁场中引入金属或通过更改0x0A 寄存器)或通过更改0x09寄存器中的调制深度(100% OOK 导致该问题,任何7-30%之间的 ASK 调制似乎解决了该问题)。   "。 基于 SLOC297的最新代码库是否仍然如此？

 -在您的一个回复中、您提到"我引用了 SLOC300、其中固件在多个电路板上都可以正常工作。" 我很惊讶 SLOC300可以正常工作、而不是 SLOC297。  

Unknown 说：

如下图所示、我们确定通过在 TX 确认后添加延迟、我们可以暂时解决该问题。  然而,延迟的长度有一个奇怪的效果。

您知道在哪里添加延迟。 它是从一些归档的帖子你引用吗? 我问的原因是与一位专家谈话(他不再与我们的团队合作)、他说没有理由增加任何延迟、尽管有几个帖子似乎是通过增加延迟来解决问题、而不真正知道为什么需要延迟。  

Unknown 说：

我们还尝试了其他硬件、包括我们的晶体振荡器和电容器、但没有任何用处。  然而、在弯曲电路板时观察到了一种有趣的效果。  向下按压电路板时、弯曲电路板可显著增加故障、而从底部向上按电路板可显著减少故障。  另外、使用塑料镊子轻轻地对 TRF IC 的两侧施加压力也可以看到这一点。  这使我们相信这是一个硬件问题。  我们验证了焊接和电路板走线均良好。

您是否尝试过使用 TI 硬件？ 你能重复同样的腐败吗?

尊敬的 Charles：

下面按顺序列出了我对您问题的回答：

• 是的、 遇到错误的字节是通过 SPI 从 TRF 发送到 MSP 的 UID 的最后一个字节。  如果我们还读取 CRC 的额外2个字节、则在发送的 CRC 的最后一个字节上发生错误。  它始终是从 FIFO 读取的最后一个字节。
• 是的、取消调谐天线并使用 ASK 调制仍然可以解决 SLOC297和 SLOC300的问题。
• 我很抱歉这里的混淆。  这意味着、基于 SLOC300的代码在整个开发过程中可在多个板上成功运行、但我们发现了几个显示此故障的精选板(运行 SLOC300)。  这就是我们认为可能是硬件问题的原因。  鉴于此问题仅出现在选定的主板上(且每个主板都因选定标签而出现故障)、因此很难理解会影响多少主板。  一个板上出现故障的标签将在另一个板上传递、反之亦然。
• 我们确实参考了多个存档的帖子、尽管增加延迟的原因是理论上、TX 中断和 RX 中断之间的时间过短可能会导致该问题。  虽然我们知道这不是中断功能的方式、但我们决定无论如何尝试、对结果同样感到惊讶。
• 由于此问题仅发生在与选择标签配对的部分电路板上、因此我们认为 TI 硬件可能不会遇到该问题。  如果我们更换了 TRF IC、但电路板数量有限、这是最后的选择。

您好 Brendon、

Unknown 说：

是的、 出现错误的字节是通过 SPI 从 TRF 发送到 MSP 的 UID 的最后一个字节。  如果我们还读取 CRC 的额外2个字节、则在发送的 CRC 的最后一个字节上发生错误。  它始终是从 FIFO 读取的最后一个字节。

好的。

• 是的、取消调谐天线并使用 ASK 调制仍然可以解决 SLOC297和 SLOC300的问题。

我无法理解为什么天线和问可以解决该问题。 针对去调和调制、您到底发生了什么变化？ 您能否显示与原稿相比更改了哪些设置？

Unknown 说：

I 歉意这里的困惑。  这意味着、基于 SLOC300的代码在整个开发过程中可在多个板上成功运行、但我们发现了几个显示此故障的精选板(运行 SLOC300)。  这就是我们认为可能是硬件问题的原因。  鉴于此问题仅出现在选定的主板上(且每个主板都因选定标签而出现故障)、因此很难理解会影响多少主板。  一个板上出现故障的标签将传递到另一个板上、反之亦然。

我想您在这里提到的所有电路板都具有相同的设计、对吧？

我想您在这里提到的所有标签都是来自同一供应商的相同15693 RFID 标签、对吗？

对于那些失败的标签、您是否可以使用 TI 硬件来读取它们？ 您是否发现同样的问题？ 结果是什么？

Unknown 说：

我们确实咨询了多个存档的帖子、尽管添加延迟的原因是理论上、TX 中断和 RX 中断之间的时间过短可能会导致该问题。  虽然我们知道这不是中断函数的方式、但我们还是决定尝试它、对结果同样感到惊讶。

如前所述、我们的专家认为不需要延迟、而是每个周期都需要 SOFT_INIT。 我知道您在每个周期中都有 SOFT_INIT、但没有任何影响、这表明这可能不是软件问题。 TX 完成后、接收7字节 UID 需要相当长的时间、因为传输 仅以106kbps 的速率进行、这比 SPI 波特率慢得多。   

Unknown 说：

由于此问题仅发生在与选择标签配对的特定电路板上、因此我们认为 TI 硬件可能不会遇到该问题。  如果我们交换了 TRF IC、但出现故障的电路板数量有限、这可能是最后的选择。

如果 TI 硬件无法重现问题、则不太可能出现软件问题、但应更多地关注硬件设计。 如您所述、通过推动、弯曲或弯曲电路板、可以对结果产生正或负偏置。 ABA 交换测试是一个好主意。 如果您可以将已知良好的 TRF7970A 芯片从其中一个正常的电路板更换为故障电路板、并且您可以重复故障、那么您需要调查该电路板。  

尊敬的 Charles：

对于调制、寄存器0x09的值从0x21更改为0x20 (例如、对于10% ASK)。  其他 ASK 调制也起作用、但只有 OOK 100%看到了这个问题。

所有电路板采用相同设计。  该问题发生在 ICODE 系列的各种不同风格的15693标签上、包括 SLIX、SLIX2和 DNA。

一个重要的发展： 我们执行了 ABA 交换、并验证问题是否出在 TRF IC 上。  我们收集了一个正常工作的电路板(电路板 A、TRF A)、上面有一个通常在易出错电路板(电路板 B、TRF B)上失败的标签。  已从两块电路板上卸下 TRF IC 并交换。  带有 TRF B 的电路板 A 显示了这个问题、而具有 TRF A 的电路板 B 没有错误地工作。  这表明我们的电路板设计正常工作、不会导致问题、并且 TRF IC 存在一些内部缺陷。

遗憾的是、仍然很难识别此问题、在该问题中、容易出错的电路板必须使用数百个标签进行测试才能找到故障。  我们的一些"良好"主板测试了数百个标签、可能需要再测试数百个标签、以可能引发问题、这仍然令人担忧。   必须制定某种筛选方法、以防止此类有缺陷的集成电路进入现场。

您好 Brendon、

 感谢您提供更多信息。 我目前在度假,我会调查你的问题,当我回来的时候,星期四. 我的回复可能会出现延迟。  

您好 Brendon、

Unknown 说：

对于调制、寄存器0x09的值从0x21更改为0x20 (例如、对于10% ASK)。  其他 ASK 调制也起作用、但只有 OOK 100%看到了这个问题。

在 ABA 交换测试之后、除 OOK 外、所有 ASK 调制深度是否都能以100%的频率工作？

经过 ABA 交换测试后、有些弯曲、推动或弯曲电路板会纠正该问题是否仍然属实？

感谢 ABA 结果。 带有 TRF B 的电路板 A 是否像具有 TRF A 或更不易出错或更容易出错的电路板 A 一样容易出错？

Unknown 说：

不幸的是、仍然很难确定此问题、即容易出错的主板必须使用数百个标签进行测试才能发现故障。  我们的一些"良好"主板测试了数百个标签、可能需要再测试数百个标签、以可能引发问题、这仍然令人担忧。   必须制定某种筛选方法、以防止此类有缺陷的集成电路进入现场。

通常、 ASK 调制具有比 OOK 调制更抗干扰的优势。 我并不感到惊讶、在数百次测试后出现噪音时、使用 ASK Than OOK 可解决该问题。   

我仍然有一个问题是,在观察到故障(例如损坏的最后一个字节)后,下一次读取可以恢复故障吗? 换言之、下一次读取或后续读取是否正确读取了标签？

您好 Brendon、

 您有任何更新吗？

尊敬的 Charles：

我很抱歉耽误你的时间,我没有收到你的答复通知。

是的、在 ABA 交换后、要求调制深度小于100%、并且实际弯曲 IC 仍可纠正问题。

在 ABA 交换之后、 具有 TRF B 的电路板 A 比具有 TRF A 的电路板 A 容易 出现较小的误差。但是、弯曲电路板再次增加了故障率、因此在焊接加热/冷却时、可能对焊接位置和对 IC 施加的应力进行细微调整会影响问题的普遍程度。

下一次读取不会恢复故障。  我们可能会遇到包含错误 UID 的行中的多次读取。

您好 Brendon、

 我很抱歉迟来的答复。

Unknown 说：

ask modulation depths 小于100%且物理弯曲 IC 仍可解决问题。

值得注意的是、除了 OOK 为100%时、其他 ASK 调制深度也在工作、从而调整 IC、这也纠正了该问题。 但是,我不知道如何解释为什么你看到的问题。  

Unknown 说：

在 ABA 交换之后、 带有 TRF B 的电路板 A 比带有 TRF A 的电路板 A 容易出错

我认为这是预期的、正如您之前所说、带有 TRF A 的电路板 A 完全没有错误。  我应该问的是 、与带有 TRF B 的 B 板相比、带有 TRF B 的 A 板如何。以下是您上次记录的内容。 是否更容易出错或更不容易出错或相同？

我们执行了 ABA 交换、并验证问题是否出在 TRF IC 上。  我们收集了一个正常工作的电路板(电路板 A、TRF A)、上面有一个通常在易出错电路板 (电路板 B、TRF B)上失败的标签。

尊敬的 Charles：

在 ABA 交换之后、带有 TRF B 的电路板 A 比带有 TRF B 的电路板 B 容易出现 的误差要小一些。如前所述、弯曲电路板会增加故障率、但当保持电路板正常运行而不被触摸时、故障更少。