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 - 0x01NFC: Read 2 Bytes - 0x02 0x01NFC: Read 3 Bytes - 0x03 0x01 0x02...NFC: Read 118 Bytes - 0x76 0x01 0x02 ... 0x74 0x75NFC: 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 IRQDescriptionThe device does not send (on pin 13) any interrupt requests on certain condition. The chip can go to astate in which the sending of additional interrupts during RX or TX is stopped. This happens when theStop condition is exactly aligned with the byte boundary on TX data.WorkaroundThe loading and reading of the FIFO should be coded in such a way, that the Stop condition does not falldirectly 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
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.
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
...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