[参考译文] TRF7964A：器件在额定工作温度下不工作

您好 Ralph、我错误地发布了我的问题两次、请随时删除我的最后一个问题。

1) 1)在现场退货中也未观察到问题并得到确认、自发布以来一直是问题

2)现有或生产

未设置芯片状态控制、默认为5V

未设置稳压器和 I/O 控制、默认为自动

芯片组调用后等待15ms。

我为提高性能所做的工作  

将芯片状态控制设置为5V

将稳压器和 I/O 控制设置为手动：VDD RF 为5V、其他 Vdd 为3.4V

芯片组调用后等待20ms。

3) 3)已验证读取过程中 RF 场是否正常且处于全功率状态、读取时所有电压均正确

我想知道默认、自动和手动操作的具体情况、是否有外部电路需要手动调节、数据表中是否没有清晰说明。

您好 Richard、

对于启动器、默认值和自动值是相同的。 默认设置为自动模式。

自动模式应根据输入使用最稳定的电平、但我们发现性能的变化超出了我们的预期、并且手动模式提供了控制性能的最佳方法。 但是、您的问题与自动模式不符、我们没有看到使用自动模式时出现系统故障。 导致问题的原因是手动将 VDD_RF/VDD_X 值设置为过高(通常在3V 模式下)、因此器件无法将电压驱动到设置指示的电平。

那么、将其设置为最大设置是有效的、但自动设置不起作用？ 您是否尝试过其他设置？ 我想了解某些设置是否会导致故障。

当您说等待15与20毫秒时、这是您应用其他设置还是读取标签的时间？

此外、在启动器件时、您是否执行数据表第6.11节"TRF7970A 初始化"中所述的软复位序列？

等待时间是我们读取标签之前的时间、我们尝试了17mS 的等待时间、默认情况下"不"设置寄存器、自动设置可提高标签读取错误率。 我发现手动20ms 似乎做得最好。 将一个单元从700个错误改进为我们的3600次尝试中的3次。对于射频、我认为这是可以接受的、

我是硬件工程师、我会将您的问题传递给软件。 不过、我假设不会、因为我们使用 的是 TRF7964A 中的指令、这些指令没有提到任何有关软复位的信息。

您希望我们尝试哪些设置？ 我一直在努力为制造和现场退货提供有效的解决方案。

我仍然不清楚自动和手动模式的作用是什么？ “自动”应该使用基于输入的最稳定的电平输入到什么？ 以及手动模式的功能、它使用的级别和用途

您好 Richard、

我建议使用数据第6.11节中概述的设置。 我在上一个帖子中输入了错误的器件型号、它将是您的器件 D/S 的"TRF7964A 初始化" 不过、70A 和64A 都具有此部分。 稳压器控制应该是可选的、但这是您认为最有效的、但我认为、如果设置正确、自动模式也会起作用。

15和20 ms 之间的差异以及使用最大设置的差异使我认为、在15 ms 内、射频接口可能没有得到足够的供电。 我知道对于某些智能应答器、我们建议在读取前按时读取20毫秒的射频场。 我强烈(并受过教育)怀疑您系统另一端的转发器是否适合该类别。 )

我必须稍微调整我对自动模式的评论。 我们希望该器件能够根据 VIN 处的输入电压为 VDD_RF 和3.3V、VDD_X 和 VDD_A 设置最佳电压电平、但 TRF7964A/TRF7970A 的情况并非如此。 我认为对于上一代器件、它们更适合这种情况。

但是、它实际上所做的是： 默认情况下、稳压器设置算法将稳压器输出设置为比 VIN 低400mV 的"增量电压"、但不高于 VDD_RF 的5V 和 VDD_A 和 VDD_A 的3.4V

这意味着您将失去一些可能会增加射频场输出功率的电压。

对于手动模式、您告诉设备应使用哪些设置、设备将尝试设置这些设置。 但是、如果您告诉器件使用 VDD_X/VDD_A = 3.3V 并为器件提供 VIN = 3V、则它无法满足设置要求、并且可能会出现运行问题。 因此、在进行这些设置之前、您必须了解电源设置。

通常、只要电源稳定、手动模式就能获得更好的性能。 需要注意的是、对于电池供电型应用、您需要考虑 VIN 随电池寿命的变化、并根据该变化确定最佳设置。

回到您的情况、将 VDD_RF 电压增加400mV 或将导通时间增加几秒钟、这两种情况都会使应答器有更多的时间进行充电、并表明此处的问题是有足够的时间让其准备好进行射频通信。

这是我们的初始化序列  

1. 提升 EN (GPIOA_PSOR = GPIO_PIN_25)
2. SPI 直接命令0x03
3. 等待15ms
4. SPI 直接命令0x00
5. 等待15ms
6. 按照以下说明写入配置寄存器
7. 读回配置寄存器
8. 如果 RF 发射器关闭、将其打开 (CHIP_STATUS_CONTROL |= 0x20)
9. 等待17ms (现在20)
10. 复位 FIFO 命令(0x0F)在发送完成时以及接收到字节后在中断处理程序中完成。
11. 在配置寄存器期间设置调制器和 SYSCLK 控制以及 NFC 目标方检测电平。

您好 Ralph、这是一个非常有用的解释、就像老学校的 TI 数据手册；-)非常有用。 我将详细介绍一下 我们使用的是锂离子电池、因此我将介绍我们的电源在低电压下的工作情况。 。

您好 Ralph、我们在两个不同的器件和不同的配置上使用 TRF7964。5V 输入电压的配置为"Default"、 我们在这方面遇到了问题、而且3.3V 版本的自动设置具有17mS 的延迟、生产线没有出现此问题、我们使用相同的标签。 实际上、我使用了一个显示此症状的器件、即切断5Vin、然后跳过它、使用3Vin 设置软件的自动延迟和17mS 延迟、这也解决了问题100%。  

您好 Richard、

老实说，当我们沿着兔子洞走的时候，这种情况变得越来越奇怪了。

从根本上说、如果延迟时间的增加改善了性能、则表明标签需要更多能量。

然而、在3V 输入时、输出功率为70mW、而在5V 时为200mW。 因此、在这种情况下、标签的能量将更少。 如果 IT 部门能够在没有问题的情况下正常工作、则似乎无法满足我提出的所有原因、而这些原因是5V 问题的根本原因。

在给定配置顺序的情况下、我想了解您的固件工程师是否可以尝试一次小改动。

0x03和0x00之间的15ms 延迟不是我们以前所做的、我想知道它是否会导致软复位序列出现一些异常行为。 是否可以删除并测试此项？ 理想情况下、使用以前导致故障的设置来了解该延迟是否会导致意外问题。

除了测试结果之外、通常不需要前15ms 的延迟、而第二个延迟、即0x00之后的延迟、可以减少到1ms、直到应用寄存器配置。 这样可以节省大量的设置时间。

我将继续讨论其他哪些根本原因可能导致这种情况...

您好 Ralph、肯定会做实验、我可能要等到下周一才去、因为我周五下班了、我不确定软件能不能马上去。 我同意这是不寻常的行为

Richard -

当标签读取失败时、TRF79xx 的寄存器0x0C 中返回什么内容？   

您好 Ralph、我明天应该为您提供结果。 很抱歉耽误你的时间，小工厂的篝火需要冲掉。 哦、我的软件人员说、他在首次与我分享的启动顺序中犯了一个错误。

1. 提升 EN (GPIOA_PSOR = GPIO_PIN_25)
2. 等待15ms
3. SPI 直接命令0x03
4. SPI 直接命令0x00
5. 等待15ms
6. 按照以下说明写入配置寄存器
7. 读回配置寄存器
8. 如果 RF 发射器关闭、将其打开 (CHIP_STATUS_CONTROL |= 0x20)
9. 等待17ms (现在20)
10. 复位 FIFO 命令(0x0F)在发送完成时以及接收到字节后在中断处理程序中完成。
11. 在配置寄存器期间设置调制器和 SYSCLK 控制以及 NFC 目标方检测电平。

红线混在一起。  15mS 等待出现在 SPI 命令和我原来的 POST 2和3交换位置之前

这就是我们要测试的全部三种调节模式：默认(未设置)、自动和手动

1. 提升 EN (GPIOA_PSOR = GPIO_PIN_25)
2. 等待5ms
3. SPI 直接命令0x03
4. SPI 直接命令0x00
5. 等待1ms
6. 按照以下说明写入配置寄存器
7. 读回配置寄存器
8. 如果 RF 发射器关闭、将其打开 (CHIP_STATUS_CONTROL |= 0x20)
9. 等待17ms (现在20)
10. 复位 FIFO 命令(0x0F)在发送完成时以及接收到字节后在中断处理程序中完成。
11. 在配置寄存器期间设置调制器和 SYSCLK 控制以及 NFC 目标方检测电平。

Josh、您好、遗憾的是、当前的测试方法不能让它自行了解 寄存器0x0C。 我可以告诉您、我们的终端中没有标签数据、例如下面。 我们从 TI 的另一个部门获悉、该器件存在已知问题、与计时有关？

我们得到的输出

$INVIND 'inventory cmd
00：E00700001FDBE74E、#01、M=04、A=03
CKSM：00000BF4
CMD 正常
$发明
CKSM：00000000
CMD 正常
$发明
CKSM：00000000
CMD 正常

Josh、我想问软件开发团队、他们是否可以轻松地将该寄存器转储到我们的屏幕输出中

您好 Ralph、以下是具有以下设置的结果

1. 提升 EN (GPIOA_PSOR = GPIO_PIN_25)
2. 等待5ms
3. SPI 直接命令0x03
4. SPI 直接命令0x00
5. 等待1ms
6. 按照以下说明写入配置寄存器
7. 读回配置寄存器
8. 如果 RF 发射器关闭、将其打开 (CHIP_STATUS_CONTROL |= 0x20)
9. 现在等待20
10. 复位 FIFO 命令(0x0F)在发送完成时以及接收到字节后在中断处理程序中完成。

手动模式

3600正确读取、每秒3600 @ 10C @ 1次读取

自动模式

每  秒读取1次3600 @ 10C @ 1次正确读取。 第一次读时、所有其他的都失败了

默认模式  

每 秒读取1次3600 @ 10C @ 1次正确读取。   第一次读时、所有其他的都失败了

您好 Josh、 0x0C = 02、42或44个通信错误、或者它读取补丁

我们使用的设置是我发布的这种晨默认模式、但如果我们设置为手动、它在所有温度下都能正确读取100%的时间、我们也会测试。  

1. 提升 EN (GPIOA_PSOR = GPIO_PIN_25)
2. 等待5ms
3. SPI 直接命令0x03
4. SPI 直接命令0x00
5. 等待1ms
6. 按照以下说明写入配置寄存器
7. 读回配置寄存器
8. 如果 RF 发射器关闭、将其打开 (CHIP_STATUS_CONTROL |= 0x20)
9. 等待17ms (现在20)
10. 复位 FIFO 命令(0x0F)在发送完成时以及接收到字节后在中断处理程序中完成。
11. 在配置寄存器期间设置调制器和 SYSCLK 控制以及 NFC 目标方检测电平。

另一个有趣的注意事项是、如果我们移除标签并尝试读取它、我们会在0x0c 中得到02、这是一个冲突错误？

您好 Richard、

说到提高 EN、在初始配置时、是否遵循图6-3中有关最短时间的时序图？ (如果 EN2不受 MCU 控制、则可以忽略它)。

自动模式和默认模式是相同的、因此结果匹配并不奇怪。

0x02是否仅在标签被移除时出现一次、或者是否重复出现并在标签被移除后很好地显示？ 删除时的单个0x02并不会让我感到意外、因为器件只会看到部分答案。

当收到类似错误时、应采取哪些步骤来尝试恢复并重试？ 通常、我们建议使用0x83 0x80进行软复位、重新配置、然后重试请求。 是这样做了吗？

是否可以扫描各种稳压器控制设置？ 即使在手动模式下、我也希望至少有一个或多个故障会导致故障。 这可能会在这里为我们提供一些指示。

[引用用户="Richard Ries"]我们从 TI 的另一个部门获悉该器件存在已知问题、与计时有关？

在这里、如果没有更多的上下文、我不知道这个人所指的是什么、但一般来说、时序对器件很敏感。 其中大多数源于作为一个开放式收发器的性质、它提供了很大的灵活性、因此需要处理射频通信的保护时间、响应时间、超时等方面。  

您好 Richard、

对此进行了任何更新？

仅供参考、我将从星期五开始至1月结束办公、因此如果我们本周没有取得太大进展、请记住这一点。

您好 Richard、

很高兴听到您认为已找到解决该问题的可行方法。 我喜欢这些设置调整、有时只需要像这样做一些小调整。 我希望每个系统的运行方式都一样、这样我就可以为您提供一组始终有效的神奇参数！ 并且完全理解、收集完整结果需要一些时间。

现在、我将继续将您的最新帖子标记为解决方案、但如果测试结果与预期结果不同、我们可以随时拒绝该帖子、我们可以继续集思广益、讨论我们可以转动哪些其他旋钮。

您好 Ralph、

以下是测试结果、该器件似乎仅根据数据表在以3V 电压运行时运行、任何5V 运行都会出现某种问题。 《具有20ms 延迟的手动4.7V》修复了一些问题、但会使其他问题变得更糟。  

我认为 TI 可能需要实施筛选流程、并在将这些流程发送给我们之前、在默认电压为5V 且延迟为15mS 的情况下对其进行测试。

Inv cnt 是我们要求器件获取标签信息的次数、而 Tag cnt 是我们正确接收标签信息的次数、而误读是差异。

您好 Richard、

只要有人遇到类似问题、就只需更新线程即可。

由于在调试继续时共享敏感信息、因此对该功能的支持被拉离线、但电流可以说：

1) 1)器件的测试方法不包括尝试读取 x 个延迟的标签、因此需要做的是跟踪问题的根本原因(电压、电流等) 如果我们要实施任何类型的测试屏幕、则可以进行测试和筛选。

2) 2)我还不相信、即使进行更费力的测试、这也会是器件级问题、因为我们支持了大量使用5V 的客户。 对我进行更严格的测试导致容差失败的情况可能是100-200次误读... 但是、基本而言、读操作成功的基础是0、如果这是器件级问题、那么其他人也会看到这一点。

我打算在确定根本原因后更新该主题、但直到那时、支持将被脱机驱动、因此不需要仔细筛选信息。