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

您好、

 问题是在第一个读取周期中发现的、还是您可能反复读取 UID、而您看到的是较晚的读取周期之一？ 换句话说、您需要多长时间才能看到 E0被 CRC 覆盖？ 启动读取周期时、是否执行了软初始化？  

 您是否也可以检查0x18处的寄存器是否已初始化为0？

 另请告诉我您是否参考了 TI 示例固件(SLOC297)？ 如果运行 SLOC297固件、是否遇到相同的问题？

尊敬的 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 可解决该问题。   

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

尊敬的 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 容易出现 的误差要小一些。如前所述、弯曲电路板会增加故障率、但当保持电路板正常运行而不被触摸时、故障更少。