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.

Starterware/TRF7961: Fail to write and read RFID tag randomly

Part Number: TRF7961
Other Parts Discussed in Thread: TRF7970A, TRF7964A, TRF7960, TRF7960A

Tool/software: Starterware

hello Ralph,
maybe you misunderstand me on tri-state. surely I will follow and implement TI recommendation into new design, just now there is one problem happened,Which drive me to know more detail on it:
Problem: the system operate long time,such as 300 minutes,more or less(one time to write and read RFID tag/minute),when MCU ask RFID controller to write or read from/to RFID tag, the command is failed. the problem is randomly,sometime happened,sometime never happen.
currently I am troubleshooting it, the schematic follow  the reference design and reviewed by TI, and antenna performance is listed in attachment, but I am still not sure where is the problem,can you give me some hints?I summarize the possible reasons as below:1.Antenna performance?2.SPI communication(no tri-state buffer)3.SW is not stronger.4.RFID controller design not stable?is there other reason?and is there any way to fix the problem?any conter measure to solve the problem?

thanks a lot;

Antenna test report - 20170811.pptx

  • Hello Mike,

    First questions to help debug:

    1) Did you receive an IRQ interrupt for the attempted tag reply, or no reply at all?
    2) If so, what IRQ status was returned?
    3) If you re-issue the read or write request does it work?
    4) If no, what steps must be taken until communication is restored?

    The antenna looks very good from what you attached.

    Couple comments on schematic:
    1) IRQ line shouldn't have that RC circuit on it. Leave it connected to MCU with no Resistor/Cap
    2) No caps are needed for EN or I/O_4, however EN needs a 10k Pulldown resistor.
  • hello Ralph,
    see my comments:
    1.due to no free pin for MCU, IRQ is not connected to MCU but pullup;
    2.see item 1 commnet;
    3.in SW, i will try to read /write three time if the request doesn't work;
    4.in current software, there is no counter measure or solution to restore communication;i have to power down system and power on it again ,then It can work again;
  • Hello Mike,

    You need to be using IRQ. This is a very complex device and not having IRQ is going to hinder your usage heavily. If you aren't using IRQ, you need to at minimum be polling the IRQ Status Register until you either hit a timeout you determine in software or receive a result you can operate with (0x80, 0x60, 0x40 etc.).

    Without knowing what IRQ status you get back, I can't even begin to debug.

    As far as retries not working goes, the only suggestion I can provide is when you have a failure is to send a 0x83 0x80 direct command sequence to reset the device and then re-configure all registers and try again.

    Again, if you aren't using IRQ, there isn't much I can help with. Every single application I have ever debugged has IRQ connected and we rely on the information of when IRQ triggers and what it reports back to give guidance on what is occurring and how to solve it.
  • Hello Ralph,
    Which document show 0x83,0x80 can reset rfid controller?
  • Hello Mike,

    For the TRF7961, that probably isn't documented well if at all - it's a very old device. Items like that was uncovered during firmware development for the TRF7970A. For the TRF7970A this is mentioned in Section 6.10.5 and Section 6.11.

    Also I used the full SPI command - the Direct Commands are 0x03 and 0x00. To send Direct COmmands with SPI, Bit 7 must = 1, which means the actual SPI commands 0x83 (Direct Command + Command Code 0x03) and 0x80 (Direct Command + Command Code 0x00).
  • Hello Ralph,

    due to IRQ is not used in my design,MCU don't know when the problem happen.i implement"0x03 and 0x00"before each time to write/read RFID tag,do you think it is fine?

    by the way, what's is the big difference between soft reset and power on-reset?

    this Monday I will try the new software and I hope this problem can be fixed. to be honest,it's a bit horrible for this problem.

  • by the way,for inductor 150nH and 330nH,'0805CS-331XJLB and 'MCFT000118 are used,can you help check they are fine for this application?
    hk.element14.com/.../2286428
    hk.element14.com/.../1711836
  • Mike -

    the sending of the 0x83 (soft init), 0x80 (idle) upon bring-up applies really only to the TRF7970A and the TRF7964A devices.
    The SPI in the TRF7960, -60A, -61, -62A and the -63A are the same as each other and different than the aforementioned parts.

    you can check here, too ==> www.ti.com/.../sloa168.pdf

    as Ralph mentioned, your decision to not use the IRQ line to signal the MCU is not ideal. In the 12 years or so that i have supported this device family, i have not seen many folks do this, and those that have made this decision are left with the requirement in their system to software poll the IRQ status register, which is also not ideal from both a code flow and power savings perspective. My sincere recommendation is for you to find a way to connect this line and use it.

    the inductor choices you show look OK to me, they look to be able to handle the current.
  • Hello Mike/Josh,

    The 0x83 0x80 sequence isn't a requirement for SPI bring up for the TRF7960A devices as it is in the TRF7970A/TRF7964A, but it does reset internal state machines and places the device in a known good state upon receiving communication failures and errors. Since without IRQ it is unknown what the error is, the only possible recourse is to soft reset the device and see if it succeeds afterwards.

    As for soft reset vs power cycle, there isn't a lot of difference in my experiences, but occasionally pulling EN low will help solve issues which even a soft reset won't but it's been very rare to see this. The biggest difference I can think of would be that with pulling EN low is that the SYS_CLK will be either at 60kHz (EN2 = 1) or fully disabled.

  • Ralph -
    I agree with that.
  • Hello RaLPH, Hello Josh,
    thanks for your response especially in the weekend;i am a little confused now :
    is 0X83 0X80 only useful for TRF7970A/64A?is it not useful for TRF7961?if it's not useful to TRF7961, it make no sense to implement 0x83/0x80 into software, right?
  • Hello Josh,
    thanks for your response especially in the weekend;i am a little confused now :
    is 0X83 0X80 only useful for TRF7970A/64A?is it not useful for TRF7961?if it's not useful to TRF7961, it make no sense to implement 0x83/0x80 into software, right?
  • Mike -
    to be clear - you need to use the IRQ line if you want to make your design the best it can be.

    All TRF79xxA devices use these commands individually for their intended purpose.

    the specific usage of the soft init and idle after power up command sequence combination was specifically used for making sure the SPI of the TRF7970A or the TRF7964A initialized correctly (this was documented workaround for a small bug)
  • Dear Josh,
    for sure I try to connect IRQ line if the MCU resource can be optimized;
    as you said 0X83 0x80 is documented and useful for TRF7970A/64A;
    I want to confirm : is 0X83 0x80 also useful for TRF7961,or ,it's not useful at all for TRF7961?please give the clear information;
    thanks.
  • Mike -
    sending the soft init or idle commands do what they are documented to do to with all the TRF79xx devices.
  • Dear Josh,
    sorry that I can catch it very clearly, 0X83/0X80 is not documented in TRF7960/TRF7961, does it mean that the command is not useful for TRF7960/TRF7961?
    thanks.
  • see table 6-31, page 31, first two commands in that table
    www.ti.com/.../trf7961.pdf

    0x00 is soft init, 0x03 is idle. when the direct commands are issued, bit 7 of the command is set '1', making the complete byte of the command as viewed with a logic analyzer a 0x80 or 0x83.
  • Dear Josh,
    I got it now,thanks a lot.it must be deep night now for you,so good night.
  • Hello Josh, hello Ralph,

    as you suggested to add IRQ to MCU, and I have check IRQ status register, and I find that there are following failure mode,can you tell me failure reason  and the corresponding mitigation on HW and SW?

    B0~B4 error interrupt:CRC,plarity,no response,collision,EOF/Framing error.

    mthanks a lot

  • Page 29 shows the bit definitions of the IRQ Register
    www.ti.com/.../trf7961.pdf
    do you mean here you are getting 5 errors at once? (i.e. you get a 0x1F?)

    i would suspect the antenna tuning first, if you are sure you are using a known good tag and the TRF79xx circuit has been modified to have all the corrections made to it.
  • hello Ralph, Hello Josh,

    our software engineer have implement 0x83/0x80 into software reset before each time to read/write tag, and there is no problem found. thanks for your suggestion.

    but I still don't know why this problem happened, software issue or HW issue, or others? as you suggested, I add IRQ signal to MCU, how can I troubleshoot it? should I monitor IRQ STATUS(0x0c),or other register?

    according to our software, if data(1~250) is failed to read or written into RFID tag three times, SW engineer shall write zero into tag, but every time they can succeed to write zero into tag.it's very strange.is there any difference to write  the data between zero and (1~250)?

    thanks. 

  • Hello Mike,

    mike zeng said:
    but I still don't know why this problem happened, software issue or HW issue, or others?

    If anything it could be considered a device issue. What happens is after failed transmissions or many many successful ones, the internal state machines of the TRF79xx devices can end up in an unknown state and then the device will exhibit communication issues. To prevent this, the soft reset process is used after any received failure and after each polling/data communication cycle as permitted by NFC standards (such as when maintaining continuous connection, this is not done until the connection drops).

    mike zeng said:
    as you suggested, I add IRQ signal to MCU, how can I troubleshoot it? should I monitor IRQ STATUS(0x0c),or other register?

    The IRQ signal should be routed to an interruptable GPIO on the MCU and an ISR should be written to read the IRQ status register when an IRQ is received and then call an IRQ Handler to process the result. From inside the IRQ Handler, decisions can be made about next steps for firmware based on received values. See TI Example code for examples of well defined IRQ Handlers.