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.

TRF7970 Missing IRQs

Other Parts Discussed in Thread: TRF7960

SLOA159 says:

The device does not send (on pin 13) any interrupt requests on certain condition. The chip can go to a

state in which the sending of additional interrupts during RX or TX is stopped. This happens when the

Stop condition is exactly aligned with the byte boundary on TX data.

The workaround should be:

The loading and reading of the FIFO should be coded in such a way, that the Stop condition does not fall

directly on the TX byte boundary.

What is meant with "stop condition". Is it the stop condition of eg. the SPI interface  (rising edge of the slave select signal) ?

What is meant with "TX byte boundary" ?

How can this be done practically ? Can you show me the part of the sample code ( out of SLOC250 ) where this is done in practice ?

Thank you...

 

  • Hi !

    I also would like to implement this workaround and have the same questions !

    Maybe somebody from TI can give us more detailed information about this workaround.

    Another question to this workaround:

    Is there a way to reset the chip, if it is in this "error" mode, when it triggers no more interrupts ?

    best regards,

    Martin

  • C'mon TI,

    if you advice a workaround for a problem you should can tell us how it is done practically or give a code example.

    Isn't this workaround part of the demo code yet ?

    Regards

    Rolf

     

  • Hello,

    i got the FIFO handling working for NFC standard frames 212k/424k, both for TX and RX.

    But I still got a problem on the RX (Target) side.

    I wrote a test application where the initiator transmits a frame every second, starting with size = 1 and ending with size =255 where the FIFO low level  is 32 bytes in my case.

    On the receiver side the frame is also correctly received until size = FIFO high level (i tested it with different FIFO high levels, the result is always the same).

    e.g. TRF_FIFOHIGH_120:

    NFC: Read 1 Bytes - 0x01
    NFC: Read 2 Bytes - 0x02 0x01
    NFC: Read 3 Bytes - 0x03 0x01 0x02
    ...
    NFC: Read 118 Bytes - 0x76 0x01 0x02 ... 0x74 0x75
    NFC: Read 119 Bytes - 0x77 0x01 0x02 ... 0x75 0x76

    As soon as 120 Bytes are reached, the irq pin keeps staying high, regardless of reading the irq status register.

    Reading the irq status register always returns 0xFF after 120 Bytes are reached.

    The TRF seems to be in an undefined state in this case.

    After reading the firmware design hints, i found something that could have to do something with this strange behaviour:

    Missing IRQ
    Description
    The device does not send (on pin 13) any interrupt requests on certain condition. The chip can go to a
    state in which the sending of additional interrupts during RX or TX is stopped. This happens when the
    Stop condition is exactly aligned with the byte boundary on TX data.
    Workaround
    The loading and reading of the FIFO should be coded in such a way, that the Stop condition does not fall
    directly on the TX byte boundary.

    What exactly does this mean? I think there was a thread on this some weeks ago (this thread), maybe someone could explain this a little bit more in detail.

    (found the related thread: http://e2e.ti.com/support/low_power_rf/f/667/t/169503.aspx)

    But the TX- buffer handling seems to work, or will there also be a surprise in some mystic cases?

    Regards Marco

  • Hello,

    my problem is solved:

    based on following source (for nfc) , the RX-FIFO handling works now for frame payloads up to 255 Bytes (including size byte)

    http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer-Discussions-Components-Files/667/8030.NFC_5F00_P2P_5F00_02_5F00_29_5F00_12_5F00_v2.zip

    Anyway, I do not think that this answers the "Lost IRQ/Missing IRQ"-question. I would also be appreciated, if someone from TI could explain the problem a little bit more in detail.

    Regards Marco

  • Hi Marco,

     

    could you please explain in a few words what exactly was the problem and how the demo source code fixed it ?

    Thank you

    Rolf

    ...and i strongly support your request about the "Lost IRQ/ Missing IRQ" problem. Please TI, give us more information...

     

  • Hello Rolf,

    the problem was, that the TRF was in some undefined state. I do not know why, that's why I would also be appreciated to get some more information on the topic "missing IRQ" to check if this was the causale.
    I just took the code of TI and implemented their RX irq routine with some changes required for my project, this works for me now.

    Current approach (as done in 8030.NFC_5F00_P2P_5F00_02_5F00_29_5F00_12_5F00_v2.zip): Without CRC and other handling:

    irq_srx is set, thus i read the FIFO status register and read the amount of bytes out of FIFO.

    If irq_fifo is also set,  I check  if there is still something in the FIFO by re-reading the FIFO status register. If not, Frame RX is complete. Otherwise wait for next irq_srx/irq_fifo. This works good as long as T_fifo_readout > T_fifo_byte_in and I do not have any problems at NFC 424 and the other 2 baudarates from framesize 1 to 255.

    If there was no irq_fifo, it can only be the  irq_srx thrown at RX-complete. No need to re-read FIFO status register, as all bytes are read out of FIFO yet.

    Regards Marco

  • Thank you Marco.

    Concerning the topic "missing irq" :
    When reading TPs (ISO15693) periodically (every 1 second or so), I constantly get the problem that TRF7970 stops giving IRQs after some time (some minutes...). Even "SoftResetting"  the TRF (Command) does not help in those situations. Related to the problem ?
    Josh ?
    By now I guess that actually there may be no workaround for the problem. If TI had one, they would have told us.
    Josh ?

    Regards Rolf

     

     

  • I'm working with another component, the TRF7960, but I had the very same problem. After a while (sometimes minutes, sometimes seconds), the component didn't generate the IRQ. I tried to understand the workaround, but it isn't clear at all. So, I implemented a timeout. If the interrupt didn't occur 10ms after the TX message I resetted the component. And the reset was a clearVal followed by a setVal at the enable pin. And this is working fine!!

    I know that isn't the best way to make things work, but in my case, it really doesn't matter.

    So, to whoever this might have been useful, happy resetting!!