• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 16 subscribers
  • Views 504 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TRF7970A: unable to receive a 998 byte NDEF reccord from tag

Robert Abad
Intellectual 470 points
Part Number: TRF7970A
Other Parts Discussed in Thread: RF430CL331H

Hi all,

We have some data stored on a type4 tag.  The data is 998 bytes (including NDEF header).  When we try to transfer this data via NFC-B from tag to reader, the reader starts sending NACKs.  Here is a Saleae logic analyzer capture of the I2C data from the MSP 430 to the RF430 on the tag and SPI data from the TRF7970A to our MCU (STM32L4).

www.dropbox.com/.../cal_request2.logicdata.zip

At ~0.04256 secs, an read binary response is sent with an NDEF LEN of 998.

At ~0.04484 secs, we then put a read binary command in the TRF7970A's FIFO.

At ~0.046065 secs, the TRF7970A generates and interrupt saying that the previous read binary command has been sent.

At ~0.06277 secs, the tag's MSP430 starts sending data via I2C to the RF430.  This is the beginning of the 998 byte data transfer.

However, the TRF7970A never sees this data.  Or at least, an interrupt on the TRF7970A stating that it's started to receive this data is never generated.  At ~0.078490 secs, the reader starts sending NACKs to the tag.

Could you please shed some light on why I am seeing this behavior?  Why doesn't the TRF7970A start receiving this data?  Why isn't it generating an interrupt that it's starting to receive it?

Regards,

Robert Abad

  • 0
    TI__Guru*** 128125 points
    Hello Robert,

    Sorry for the delay, I reviewed your logic file and what I am seeing is that before the IRQ fires, the TRF7970A is trying to send a data packet. Data packets are sent by clearing the FIFO first, so it looks like the FIFO was cleared before the IRQ arrived and then when checked it was empty.

    I think the TRF7970A isn't waiting long enough for the packet to be received, so that may need to be a timing adjustment made in terms of the timeout before trying to send out the next command (which was a NAK). You also can check from configuration what the timing agreement on timeout is between the two devices and measure if the RF430CL331H is sending the data quickly enough.
  • 0 in reply to Ralph Jacobi
    Intellectual 470 points
    Hi Ralph,

    Thank you for taking the time to look at our data file.

    Can you point me in the right direction in how this timeout in the TRF7970A is set?

    You mentioned a configuration a timing agreement. Assuming that is set by software, where is that in the NFC stack?
  • 0 in reply to Robert Abad
    TI__Guru*** 128125 points

    Hello Robert,

    Timeouts are set based on the NFC technology, so NFC-B in this case which is in the nfc_b.c file. The data package that has the timeout agreements for Reader/Tag is the SENSB Response. Look for the variable g_ui16NfcBFwt in the nfc_b.c file.

    The timeout is then used in the nfc_controller.c file. For your application, specifically you want to look at the NFC_DATA_EXCHANGE_PROTOCOL state here:

    		ui16PICCTimeOut = NFC_Initiator_GetPICCTimeOut();

		eTrfIrqStatus = NFC_waitForCommand(ui16PICCTimeOut);

  • 0 in reply to Ralph Jacobi
    Intellectual 470 points
    Thank you, Ralph. This helped resolved my issue! :)