[参考译文] TRF7964A：配置 TRF IC 以读取 ISO15693标签类型

谢谢你。 我同意。

但令人惊讶的是、我们在其中一个产品中发现了一个有趣的问题、该问题导致 ISO15693标签的最后一个 UID 字节(E0)被损坏。 我们看到的是 E3或 EB、或者是其他版本、而不是 E0。 虽然在大约100K 读取中发生3次故障的情况下损坏率较低、但损坏模式始终保持一致。 它始终是损坏的最后一个字节(E0)。

现在、当我们在每个读取周期后向 TRF IC 发出 SOFT_INIT 时、这些错误都会消失。 我们不知道为什么？

您好！

 在 e2e 存档中、我发现有一条关于最后一个字节可能已损坏的类似发现的注释。 以下是评论,您可以试试吗?

"如果我们从 TX IRQ 线路复位到 FIFO 复位施加至少260us 的延迟、问题似乎就会消失。"

尊敬的 Charles：
根据您根据 e2e 存档的建议、我添加了从 IRQ 线路复位到 FIFO 复位的至少260us 延迟。 这似乎工作正常、问题确实消失了。 我正在对多个产品进行测试以确认相同。 因此、我的答复出现拖延。 非常感谢您的帮助。 我真的很感激。 所有这些、同时我们还在我们的代码中寻找解决此问题的其他位置、尝试了解根本原因。 这是否意味着 TRF79xx 芯片或其参考代码中存在错误？  TRF7964A 产品说明书未提及任何这方面的信息。 有什么想法吗？

尊敬的 Krishna：

 很高兴问题因延迟而得到解决。 我不知道此问题的历史、因为我刚刚开始对此设备提供支持。 可能是某种类型的竞态条件、其中复位 FIFO 命令与读取最后一个 FIFO 字节相同、通过读取该字节、增加延迟就可以解决该问题。  

尊敬的 Charles：
您能帮助我们 联系一下有此问题历史记录的人、或者其他可以帮助我们了解问题根本原因的人吗？ 此修复将在客户所在位置的一个产品中进行。 我们需要清楚地解释它们。

尊敬的 Krishna：

 这是我针对权变措施提到的帖子。  

https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1184301/trf7964a-read-single-block-issue-corrupt-last-byte/4467190?tisearch=e2e-sitesearch&keymatch=UID%2520byte%2520corruption#4467190

尊敬的 Krishna：

您能否提供以下详细信息？  

• 完整的通信链、如果可能会出错–因此开始器件上电、直到获得错误帧。 损坏的最后一个字节数据需要多长时间？ 误差百分比是多少(就最后一个字节损坏而言)？
• 详细介绍了什么是软件基础。 您是使用 TI 软件(例如 SLOC297)还是您自己的栈等

您好 Charles、Krishna 可以回复更多详细信息。  我在这里简单回复一下。   

完整的通信链- Krishna 可以填写。

损坏最后一个字节的时间因模块而异。  有时在几分钟内、有时在几个小时内、有时从不。  我们只有几个模块能够可靠地发生故障、目前为止、我们有数百个模块从未出现故障。  标签上的出错时间是一致的-如果标签在几分钟内出现故障、则它始终会同时出现故障。

误差百分比小于标签总读取的1%。  我们将反复读取标签 ID。  发生错误时、错误始终是 E0字节。  在某些模块上、标签 ID 中的 E0字节始终替换为相同的不正确字节、在其他模块上、错误的值可能会采用一些不同的值。

我们使用我们自己的软件、不确定是否有任何软件基于 SLOC297演示代码。  这将会是一个很好的答案。

谢谢！

Steve  

Steve、您好！

 感谢您的反馈。 您能否同时向我们介绍一下这些具有损坏字节的模块的 LTC (批次跟踪代码)？ 我们想了解 LTC 对于故障模块是否有重要意义。 如果可能、还请告诉我们有关良好模块的 LTC。   

我想清楚地说明一下总标签读取量的1%。 在给定一个故障模块的情况下、您将反复读取标签 ID。 假设您读取一百次、您将看到一次 UID 的最后一个字节损坏。 这是正确的理解吗？

您是否还能在拥有的模块总数中提供故障模块的数量？

如何查找 LTC？  我可以从 IC 读取它吗？  我在我的模块中看不到 IC、因为它位于屏蔽体下方。  我是否需要从我的合同制造商处获得此信息？

通常远小于1%。  在5000次读取中、我们可以看到25-50次错误。   有时只有1或2在5000次读取中失败。  模块内的故障率保持一致。

我们在几个不同的客户站点拥有数千个模块。  只有一位客户发现此故障。  此客户的10至50个模块存在故障、现场有~400个器件。

Unknown 说：

如何查找 trf？  我可以从 IC 读取它吗？  我在我的模块中看不到 IC、因为它位于屏蔽体下方。  我是否需要从我的合同制造商处获得此信息？

是的、您可以从 IC 中阅读。 在您的情况下、请从合同制造商处获取。

Unknown 说：

trf 我们正在反复读取标签 ID。

我想跟进这一评论。

它是否与您反复读取的标签相同？

如果它是同一个标签、它是否始终在收发器天线的范围内？  

我想回到 Krishna 关于读取周期的原始陈述。 您能解释一下读取周期的定义吗？ 在以下两种情况下、您的读取周期是多少？ 如果您对读取周期的定义与以下两个定义不同、请进行详细说明。  

1. 打开系统电源、使用软初始化(软复位)和 ISO15693设置初始化设备、然后在不更改 TRF 设置的情况下读取标签。
2. 您‘re‘re上电、使用软初始化(软复位)和 ISO15693设置初始化器件、并完全在构成" AD 周期"的过程中读取标签的全部内容、然后他们返回并使用软初始化等重新初始化器件(每次您开始下一个 AD 周期时、就是 TI 代码的工作方式)

如果您反复读取标记 ID、则意味着要启动新的库存命令。 在您启动新的清单命令(换句话说、启动新的读取周期)之前、您是否首先向器件发出软件复位？ 这个问题的答案非常重要。  

是的、我们使用的是 TI 软件 "sloc297c (TRF79xx_TRF79xx Eval_Board_Source)"。 我们在 SPI 上使用 PIC MCU 连接了 TRF IC。 MCU 通过 UART 接口与主机通信。

*****

完整通信链

• 我们从主机收到"Get Tag ID"命令。
• 我们重置用于标签计数的全局变量。
• 调用"ISO15693_sendSingleSlotInventory"命令、然后调用 "TRF79xxA_setupInitiator (0x02)"。
  
  • 芯片状态控制寄存器配置有 RF 开启和全输出功率。
  • ISO 控制寄存器被配置为 ISO15693缺省值"0x02"、也就是说、高比特率@ 26.48kbps、一个副载波和4选1。
  • 调制器控制寄存器设置为"0x01"。
  • RX 无响应等待时间寄存器被设定为"0x15"。
  • FIFO IRQ 电平寄存器中的可调 FIFO 电平被设定为"0x0C"。
  • NFC 目标方水平寄存器被设定为"0x00"。
  • 增益衰减设置设为默认值、即"RX Special Settings"中的0dB。
• 命令组帧(我们使用"ISO15693_sendSingleSlotInventory"函数)。
  • 调用"TRF79xxA_insertRstFIFOCmd ()"、将这些标头字节/命令插入命令缓冲区、即"Reset FIFO command"、"Send with CRC"和"Write Continuous"模式。
  •  以两个字节形式更新命令/数据包长度。
  • 将所需的标志值设置为"0x26"。
  • 将库存命令代码设置为"0x01"。
  • 将掩码长度设置为"0x00"(不发送 AFI)。
  • 调用用于发送目录命令的"_writeRaw"函数。
  • 调用"_waitRxData"函数以接收响应。 Tx 超时默认设置为5毫秒、Rx 超时默认为15毫秒。
  • 当 TRF 状态标志设置为"RX_COMPLETE"时、我们检索8字节的标签 UID。
  • 更新标记计数全局变量。
  • 将标签 UID 发送到主机。
• 如果 "ISO15693_sendSingleSlotInventory"函数失败、那么
  • 我们使用"ISO15693_resetRecursionCount"函数复位递归计数器。
  • 然后使用"ISO15693_runAnticollision"函数发送一个16槽目录命令。

*****

当我们从主机收到"Get Tag ID"命令时、我们会重复"完整通信链"下所述的相同过程。 我们的客户将循环发送此命令。

*****

我们观察到射频流中的最后一个字节、即第一个 ISO15693标签 UID 字节(0xE0)持续遭到破坏。 请注意、并不是每个周期都会损坏。

错误率已由 Steven Benoit 在其他帖子中描述过。

在器件上电开始时、我们使用"TRF79xxA_initialSettings"函数初始化 TRF 芯片、并使用 ISO15693类型标签的默认值对其进行设置。

• 是的、这与我们反复读取的标签是相同的。
• 它始终处于收发器天线的范围内。
• 我在另一篇文章中介绍了读取周期的定义。 这 是您提到的第二种情况、其中有一处不同。
  • 给系统上电、使用软初始化(软复位)和 ISO15693设置初始化器件、在一种情况下读取标签 UID、在另一种情况下读取标签存储器数据、返回并使用 ISO15693设置重新初始化(不含软初始化)、每次我们开始下一个"读取周期"。
• 在反复读取标签 ID (即启动新的库存命令)时、我们不会发出软件复位命令。

在启动新的库存命令之前、我们无法对器件发出软件复位命令、因为它会关闭射频、从而使标签断电。 我们需要让标签保持通电状态、以便进行一些高级标签操作。

尊敬的 Krishna：

完整通信链

• 我们从主机收到"Get Tag ID"命令。
• 我们重置用于标签计数的全局变量。
• 调用"ISO15693_sendSingleSlotInventory"命令、然后调用 "TRF79xxA_setupInitiator (0x02)"。
  
  • 芯片状态控制寄存器配置有 RF 开启和全输出功率。
  • ISO 控制寄存器被配置为 ISO15693缺省值"0x02"、也就是说、高比特率@ 26.48kbps、一个副载波和4选1。
  • 调制器控制寄存器设置为"0x01"。
  • RX 无响应等待时间寄存器被设定为"0x15"。
  • FIFO IRQ 电平寄存器中的可调 FIFO 电平被设定为"0x0C"。
  • NFC 目标方水平寄存器被设定为"0x00"。
  • 增益衰减设置设为默认值、即"RX Special Settings"中的0dB。
• 命令组帧(我们使用"ISO15693_sendSingleSlotInventory"函数)。
  • 调用"TRF79xxA_insertRstFIFOCmd ()"、将这些标头字节/命令插入命令缓冲区、即"Reset FIFO command"、"Send with CRC"和"Write Continuous"模式。
  •  以两个字节形式更新命令/数据包长度。
  • 将所需的标志值设置为"0x26"。
  • 将库存命令代码设置为"0x01"。
  • 将掩码长度设置为"0x00"(不发送 AFI)。
  • 调用用于发送目录命令的"_writeRaw"函数。
  • 调用"_waitRxData"函数以接收响应。 Tx 超时默认设置为5毫秒、Rx 超时默认为15毫秒。
  • 当 TRF 状态标志设置为"RX_COMPLETE"时、我们检索8字节的标签 UID。
  • 更新标记计数全局变量。
  • 将标签 UID 发送到主机。
• 如果 "ISO15693_sendSingleSlotInventory"函数失败、那么
  • 我们使用"ISO15693_resetRecursionCount"函数复位递归计数器。
  • 然后使用"ISO15693_runAnticollision"函数发送一个16槽目录命令。

Unknown 说：

trf

• 是的、这与我们反复读取的标签是相同的。
• 它始终处于收发器天线的范围内。

[报价]

 感谢您的大力支持。  

Unknown 说：

]我在另一篇文章中介绍了 trf 读取周期的定义。 这 是您提到的第二种情况、其中有一处不同。

• 给系统上电、使用软初始化(软复位)和 ISO15693设置初始化器件、在一种情况下读取标签 UID、在另一种情况下读取标签存储器数据、返回并使用 ISO15693设置重新初始化(不含软初始化)、每次我们开始下一个"读取周期"。

[/报价]

Unknown 说：

反复读取标签 ID (即启动新的清单命令)时、我们不会发出软件复位命令。

[/quote]

否 我认为这不适合第二种场景、而适合第一种场景、因为第二种场景是在读取周期之前发出软件复位。 那就是我们的 TI 准则做到了这一点。 基于此假设、对 TI 代码(SLOC297)执行了大量测试、以使用各种协议的标签。 您的描述适合第一种场景、在这种场景中、您首次发出软件复位、然后在随后的1000次中不会复位器件。 这与 TI 准则背道而驰。 在我几周前给大家的第一次答复中、我想你们要描述一个序列、如下所示、读取周期只是一个读取命令。 在这种情况下、读取命令之间无需复位器件。  

Soft INIT -> Inventory command -> Read Block (作为一个读取周期)-> Read Block (作为另一个读取周期)-> Read Block ->.....  

Unknown 说：

trf 在启动新的库存命令之前、我们无法对器件发出软件复位命令、因为该命令会关闭射频、从而使标签关闭。 我们需要为一些高级标签操作保持供电。

在我与我们的专家讨论如何处理您的独特情况时、您可以尝试在读取周期前发出软 INIT。 请告诉我结果。  

[/quote][/quote]

我已经尝试在读取周期之前发出 soft init、错误消失了。 但随后我们还发现(在对我们的产品进行全面测试后)某些高级标签操作失败。

您碰巧分享了同时适用于其他一些用户的270 us 解决方案。 所以、我注释掉了 soft INIT、并引入了 TX IRQ 和 FIFO 复位之间的延迟。 该解决方案也适用于我们的用例、但我们想找出问题的根本原因。 我们还希望相信这确实是正确的解决方案。

Unknown 说：

trf 我已经尝试在读取周期之前发出软初始化命令、错误消失了。 但是,我们也发现(在对我们的产品进行全面测试之后)一些高级标签操作失败。[/报价]

除其他功能外、Soft INIT 用于复位器件上的状态机。 TI 建议从软 INIT 开始每个读取周期、以确保器件中的所有状态机都得到刷新并且器件保持在已知良好的状态。 我认为 您应该了解高级标签操作失败的原因。  

Unknown 说：

trf 您碰巧分享了同时适用于某些其他用户的270 us 解决方案。 所以、我注释掉了 soft INIT、并引入了 TX IRQ 和 FIFO 复位之间的延迟。 该解决方案也适用于我们的用例、但我们想找出问题的根本原因。 我们也希望相信这确实是正确的解决方案。[/报价]

SLOC297和 NFCLink 独立固件堆栈(SLOA227)都在 TX_COMPLETE 之后就位了 Soft INIT。 我倾向于相信它存在有很强的理由。 添加260us 延迟可能可以为其他客户以及您的客户提供一个独特的解决方案、无法保证相同的延迟可应用于 TI 代码设计支持的所有不同协议。 虽然我会咨询我们的专家、但我会建议您在每个读取周期前对器件进行复位、并调查其他高级标签操作失败的原因。  

Unknown 说：

trf 我们在几个不同的客户站点拥有数千个模块。  只有一位客户发现此故障。  该客户的10个和50个模块存在故障(现场有~400个单元)。[/quota][报价 userid="645233" url="~/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1476404/trf7964a-configuring-trf－IC-for-read-iso15693-tag-tag-types/5697718#5697718"]通常远低于1%。  在5000次读取中、我们可以看到25-50次错误。   有时只有1或2在5000次读取中失败。  故障率在模块内保持一致。

[/quote]

此数据点表明、除了一个客户外、并非所有其他客户都需要260us。 这位特定客户呈现了不同于其他客户的独特场景。 您能解释一下这位客户与他人之间的区别吗？

[/quote][/quote]