This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] TRF7961:读取超过9个字节的数据时出现问题

Guru**** 1177430 points
Other Parts Discussed in Thread: TRF7961, TRF7960, TRF7962A
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/804992/trf7961-problem-in-reading-data-more-than-9-bytes

器件型号:TRF7961
主题中讨论的其他器件: TRF7960TRF7962A

我使用的是具有单个 RFID 标签的 TRF7961芯片。 我使用的是 ISO15693 RFID 标准中的芯片。 用于与 TRF7961通信的 MCU 是 PIC18。 使用 SPI 接口进行通信。 SPI 频率为2MHz。 我使用 SLOC247作为中断处理程序的参考。 每当发送响应大于9字节的命令时、就会出现问题、例如应该返回15字节的"Get system information command (2B)(获取系统信息命令(2B))"。 我获得的第一个中断用于传输,读取的 IRQ 状态寄存器值为0x80,这是正常的。 我获得第二个接收中断、IRQ 状态寄存器值为0x60、这意味着接收已开始、我读取 FIFO 状态寄存器、其值为0x28、这意味着 FIFO 中有9个可用字节、然后我读取这些字节。 现在、由于 SLOC 固件中的 IRQ 处理程序正在持续轮询 DO while 循环中的 IRQ 线路、我也在执行同样的操作、我看到 IRQ 线路保持高电平、我现在读取 IRQ 状态寄存器、如图所示 值为0x46、有时为0x42、但值应为0x40、这将使我能够读取命令响应中15的剩余6个字节。 我有两个问题  

1) 1)为什么我得到0x46或0x42、即使我使用的是单个 RFID 标签、我也应该得到0x40、这将是正确的值、并允许我读取剩余的字节。  

2) 2)每当要接收的数据大于9字节时、IRQ 线路在获得第一个响应中断后应持续保持高电平、直到接收到整个数据、或者我们将针对9字节的单独块获得单独的中断。 在我的情况下、在前9个字节之后、IRQ 线路保持高电平、直到我从 IRQ 状态寄存器中读取0x46。

可能导致此问题的原因是硬件或固件。

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

    首先、SLOC247不是我们的 NFC 配套资料之一、因此我不确定您实际引用的内容。 可能是 SLOA227还是 SLOC297?

    您描述的获取0x80和0x60的过程至此非常好、但我对其余的情况不太确定。 在这里、澄清您所参考的固件库非常重要、以便我可以准确地检查我们提供的代码中所做的工作并进行解释。

    我同意0x46或0x42不适合返回、也没有意义、我怀疑处理不当的事情会导致这种情况。

    IRQ 在第一次读取0x60后将变为低电平、并且在应该报告0x40之前不会再次上升。

    请帮助澄清固件、以便我进一步调查。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Ralph、
    你是对的。 我输入了错误的名称。 我使用的参考固件是 SLOC297。 我仍然会得到0x42和0x46、有时也会得到0x56。 另一个问题是、如果我们在0x60之后获得单独的中断、为什么需要轮询中断处理程序中使用的 DO while 循环中的 IRQ 引脚。

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

    IRQ 引脚的轮询不应导致您描述的问题。 如果您使用的是 SLOC297版本 C、则您拥有最新的代码、因此我假设 Do while 循环是 TRF79xxA_irqHandler 内部的那个 while 循环、对吧?

    如果是这样、当 IRQ 引脚在处理 IRQ 后保持被清除时、IRQ 处理程序将退出。 这样做的原因是、我们不希望中断触发来中断初始 IRQ 的处理、也不希望错过后续 IRQ。 因此、通过使用 DO while 环路、这允许在不中断处理的情况下处理 IRQ、但也允许在第一个中断被处理后立即检查 IRQ 引脚是否存在第二个中断。

    您是否有逻辑状态分析器、或者至少有一个示波器、此示波器能够解码 SPI 数据并显示数据包间的时间间隔? 通过查看 SPI 线路上的通信、尤其是事件之间的时序、可以更轻松地解决这一问题。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Ralph、  

    是的、我使用的是 SLOC297版本 C。我已经获取了示波器的屏幕截图、因为这是我拥有的唯一工具。 附加图像。

    发送的命令为"Get system information command (2B)"、期望响应15个字节。 第1个字节是标志字节。 第2个字节是信息标志字节。 第3个字节到第10个字节是 UID。 第11个是 DSFID、第12个是 AFI。 第13和第14个是存储器信息字节、第15个是 IC 信息字节。

    这些图像按顺序排列。 粉色探针是 IRQ 线路,黄色是时钟,蓝色是 MISO 线路。

    所有图像都是每个图像顶部显示的缩小部分的扩展版本。

    从缩小的部件中可以看到、TRF7960将中断线路拉高3次。 从第一个映像中可以看出、这是它第一次执行0x60操作。 之后、接下来的4个图像显示正在读取的9个字节的数据、正如我所检查的那样、这些数据是正确的。 它给出了与卡的 UID 相匹配的前7个字节的 UID。

    第5个图像显示下一个中断、该中断来自 IRQ 状态寄存器值0x42、该值可从 MISO 线路的中间部分读取。  从图6中可以看到、在读取0x42后、中断线再次被拉高。 但我们 进入中断处理程序的冲突检测部分(由于接收到0x42),在该部分中,我们首先发送停止解码器命令(0x16|0x80)。 之后、我们使用复位 FIFO 命令(0x8F)复位 FIFO。 最后、我们读取状态寄存器以将其清除(0x6C)。 从图像7中、您可以看到第三个中断后在 IRQ 寄存器中接收到的值为0x40、 这一值现在不起作用、因为我们已经处理了中断处理程序的冲突检测部分 、在该部分中、我们已停止解码器、 已清除 FIFO 并已清除状态寄存器。

    请帮我解决这个问题

    此致  

    Devendra

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

    您好 Devendra、

    RX IRQ 看起来太长。 处理 IRQ 的时间不应与 TX 和 RX 操作不同:

    在我们的示例中、IRQ 线路恢复到低电平大约需要~20微秒。 我不确定您的时间间隔是多少、20微秒处理速度非常快、但您的情况似乎需要很长时间。

    鉴于我无法重新创建此问题、我认为这会导致您的问题、请查看您是否可以缩短 RX 上的 IRQ 服务时间-尤其是0x40的第2个 IRQ、该 IRQ 的服务时间最长、直至被服务为止、并查看您是否获得了正确的操作。

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

    您好 Ralph、

    在 我的情况下、IRQ 线路从高电平变为低电平所需的时间为~10us 、这是我所想的。 所以我不认为这是问题。 但是、我在本例和您所附的图像中看到的一个不同之处是、发生0x60和0x40中断的不同 b/w。 从您的图像中、我可以看到、这种情况的发生间隔为1-2毫秒。 但在我的案例中、时间差 bw 0x60和0x42 (这是我得到的不是0x40的值)为80-100us、至少比您的案例少10倍。 这意味着 TRF7961过早地发送第二个中断。 这是否会导致问题。  

    此致  

    Devendra

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

    我看到、我认为我不能完全理解您最终的图像顺序、这也是我的错误、正如您解释的那样。

    第二个中断的速度非常快... 我不确定可能导致这种情况的原因、但通常这些问题最终是由于器件未正确配置或启动。

    对于您的系统、您是否同时使用 EN 和 EN2? 您是否对启动顺序进行了任何更改?

    此外、TRF7961与已在其上进行代码测试的 TRF796xA 器件略有不同、通常我们建议将 TRF7962A 用于 ISO15693应用。 您是否可以获得该器件的一些样片并对该器件进行测试? 结合使用非 MSP430 MCU 和使用 TRF7961时、可能会出现系统特定问题、而这是以前未出现过的问题。 在从事这些产品的5年里、我不支持 TRF7961的非 MSP430应用... 看到非 TI MCU 的一些初始问题不断增加、我们很难进行调试、因为我们无法使用设置重新创建这些问题、这种情况并不少见。

    不过、希望这是由于启动序列造成的。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Ralph、

    我认为我们仅使用 EN、因为我们不使用 TRF7961为 MCU 提供时钟。 无论我通过什么方法连接我们系统中使用的 TRF7961的原理图、您都可以查看该原理图。 我使用了 SLOC297中提到的启动序列、不管怎样、明天我将发送配置代码片段、因为我今天已经离开了办公室。 此外、我还将向上级介绍 TRF7962A 的使用方法。

    e2e.ti.com/.../TRF_5F00_schematic.pdf

    此致  

    Devendra

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

    感谢您分享原理图。

    匹配的网络有许多会影响性能的不一致之处。 不能确定这些变化也会导致这个问题、但这是可能的、而且一般而言、它们会对读取范围产生负面影响:

    1) 1) C711和 C713应为1500pf
    2) 2) C710应为10pF
    3) 3) C716应为27pF

    该匹配网络旨在最大限度地提高性能、已被成功的数百个客户使用、因此请修改该网络。

    与问题更直接相关的另一部分是 SPI 和 IRQ 线路上的电阻器、 我不确定可能会产生什么影响、但对于我们的系统、我们不需要额外的电阻、并且肯定不需要在这些线路上使用上拉或下拉电阻器。 我假设三态缓冲器在同一总线上具有多个 SPI 器件、但除此之外、还有许多额外的组件。 需要移除 IRQ 上拉电阻。 我建议将 R702除以、看看您是否得到相同的行为。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Ralph、

    我将要求我的硬件团队对您在之前的回复中提到的原理图进行更改。 今天、我观察到一个奇怪的现象、我在 TRF7961周围晃动标签时偶尔获得正确的输出。 每当我获得正确的输出时、我都会在代码中放置一个中断、并启动计数器、在我获得正确的输出之前检查计数数量。 没有获得正确输出的固定时间。 有时我会在第三次迭代中得到它、有时在第30次迭代中得到它、有时在第100次迭代中得到它。 此观察结果是否有助于您诊断问题? 我不认为这是固件问题、因为我有时会获得正确的输出。 这是否是天线或其他硬件的问题?  

    下面提到的是我在循环内持续执行的启动序列和命令。

    此部件是 ISO15693的设置

    G_sTrfStatus = TRF_IDLE;

    //软初始化命令  

    SEND_COMMAND (0x83);//14
    ///IDLE 命令
    SEND_COMMAND (0x80);//15

    //设置1ms 延迟
    延迟(1);

    SEND_COMMAND (0x8F);//17

    WRITE_A_register (0x09、0x01);//18
    WRITE_A_register (0x0B、0x01);//19

    WRITE_A_register (0x00、0x20);//20

    WRITE_A_register (0x01、0x02);/21
    WRITE_A_register (0x09、0x01);/22
    WRITE_A_register (0x07、0x15);/23
    WRITE_A_register (0x08、0x1F);//24

     延迟(20);/25

     


    此部分用于发送命令

    buf[0]= 0x8F;
    buf[1]= 0x91;//随 CRC 发送
    buf[2]= 0x3D;//从1D 写入连续
    BUF[5]= 0x02;// ISO15693标志
    BUF[6]= 0x2B;

    大小= 0x02;

    buf[3]=(char)(大小>> 8);
    buf[4]=(char)(大小<< 4);

    SpiRawWrite (&buf[0]、7);

    TRF79xxA_waitTxIRQ (5);
    TRF79xxA_waitRxIRQ (15);

     

    我将在环路内持续执行此操作、以便与单个 RFID 标签进行复制

     

     

    此致

    Devendra Singh

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

    打开射频场和向标签发送命令之间的延迟时间是多少?

    周期之间有多长时间?

    您是否在每个周期重置并重新配置器件?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Ralph、

    在打开射频场和发送命令之间、我有20ms 的延迟。 一旦我从 TRF7961中获得响应、周期之间就没有时间。 是的、我在周期结束时关闭射频、并在周期开始时再次重新启动。 我将在每个周期重新配置器件。  我在两个周期之间唯一的延迟是接收 RX 中断的延迟、如 TI 参考代码中所述、该延迟为15ms。 我正在使用参考固件  TRF79xxA_waitTxIRQ (5);TRF79xxA_waitRxIRQ (15)中提到的这两个例程 来等待 RX 和 TX 中断。 收到它们后、我将立即返回到新周期的开始、并再次按照我之前电子邮件中的启动序列中所述、将器件配置为 ISO 15693模式。 这种方法有什么问题吗? 我这样做是因为我想确保至少一个命令运行良好、然后我将执行其他命令。   

    此致  

    Devendra

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

    我建议进行以下测试:

    1)尝试其他 ISO15693命令、这两种命令都需要超过9字节的应答、以及需要更少字节的应答。 库存和读取单个数据块将是这种情况的良好选择。 如果"获取系统信息"是唯一存在问题的命令、则可能与标签相关。

    2) 2)尝试关闭环路末尾的 RF 场、然后在它返回复位器件之前再增加10-15 ms 的延迟。 这将减慢过程、还允许重置标签。 通常情况下、器件不会在复位和传输之间持续振荡、因为这不是标准通信、因此环路可能会影响这一点。

    3) 3)进行建议的硬件更改、并确保使用多个标签进行测试。 有时不同供应商的标签的性能会有所不同。

    除了这些建议之外、我还可以提供很多其他的指导、因为系统设置是使用我无法访问的 MCU、因此我无法在我的末尾进行任何测试 总的来说、除了器件所进入的无限循环之外、您的软件看起来还不错、但硬件问题需要解决。 但是、如果这些问题都不能解决、我就不会有其他想法、因为我通常会在这样的情况下看到基于软件的问题、这些问题由于您一直密切关注 SLOC297而不存在。 如果它最终是特定于系统的、因为我无法重新创建系统设置、我无能为力。

    希望上述建议之一能解决这种情况。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Ralph、

    感谢您的大力支持。 我一定会尝试这三个建议。 希望这些可以解决我的问题。
    周末愉快! 干杯!!


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

    您好 Ralph、  

    将芯片控制寄存器(0x00)中的 B2位置位(在 TRF7961数据表中被称为保留位)后、命令已经开始为我完美工作。 对该位的重要性有什么想法吗?  

    此致  

    Devendra