• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 16 subscribers
  • Views 776 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: Not Responding to certain commands

nick crljenica27
Prodigy 70 points
Part Number: TRF7970A
Other Parts Discussed in Thread: MSP430F47187,

Hi All

I am using TRF7970A connected to MSP430F47187 via SPI

Most of the operation is working fine.

My problem is that TRF7970A does NOT respond to some of the commands.

Is there an error code that can be read and/or a list of responses (actual hex codes to particular command),

I have not been able to find.

I have a same problem using my source as well as TI example code.

Appreciate your help

nick

  • 0
    TI__Guru*** 128255 points
    Hello Nick,

    What type of commands have the issue? SPI commands? Or RF commands? If RF commands, what mode are you using?

    Also which example code are you seeing the issue with?
  • 0 in reply to Ralph Jacobi
    Prodigy 70 points
    Thanks Ralph
    Here is a sample code that is an issue.

    uint16_t NDEF_readBinary(uint16_t ui16FileOffset, uint8_t ui8ReadLength)
    {
    uint8_t ui8Offset = 0;
    uint16_t ui16NLEN = 0;

    #ifdef ENABLE_HOST
    volatile int x, n;
    #endif

    g_pui8TrfBuffer[ui8Offset++] = 0x8F; // Reset FIFO
    g_pui8TrfBuffer[ui8Offset++] = 0x91; // Send with CRC
    g_pui8TrfBuffer[ui8Offset++] = 0x3D; // Write Continuous
    g_pui8TrfBuffer[ui8Offset++] = 0x00; // Length of packet in bytes - upper and middle nibbles of transmit byte length
    g_pui8TrfBuffer[ui8Offset++] = 0x60; // Length of packet in bytes - lower and broken nibbles of transmit byte length
    g_pui8TrfBuffer[ui8Offset++] = 0x02 | g_bBlockNumberBit; // I-Block PCB: Read Block 0 or Block 1, with CID = 0, NAD = 0, no chaining
    g_pui8TrfBuffer[ui8Offset++] = 0x00; // CLA
    g_pui8TrfBuffer[ui8Offset++] = 0xB0; // INS = Read Binary
    g_pui8TrfBuffer[ui8Offset++] = ((ui16FileOffset >> 8) & 0xFF); // File Offset where to start reading data
    g_pui8TrfBuffer[ui8Offset++] = (ui16FileOffset & 0x00FF); // File Offset where to start reading data
    g_pui8TrfBuffer[ui8Offset++] = ui8ReadLength;

    g_bBlockNumberBit = 1;
    t ui16FileOffset = 0;
    t ui8ReadLength = 2;

    I do receive TX interrupt only.
    Tried to change timing, no difference.

    thanks and take care
  • 0 in reply to nick crljenica27
    TI__Guru*** 128255 points
    Hello Nick,

    Thank you, that makes it very clear!

    The example code in SLOC297 for NDEF reading is very rudimentary. It doe not include full support for NDEF message reading unlike our full NFC stack. For SLOC297, many of the NDEF variables are hardcoded, so you will need to do the one of the following:

    1) Use SLOA227 NFC Reader/Writer code which provides full NDEF support
    2) Modify the NDEF layer to adapt proper NDEF handling

    I recommend taking step 1, as SLOC297 was never designed to be NFC compliant while SLOA227 was and has been tested against NFC Forum NDEF standards. But if you prefer to take step 2, you will need to either get the official NFC Forum specs from the NFC Forum to follow along or use SLOA227 as a baseline for implementation regardless.
  • 0 in reply to Ralph Jacobi
    TI__Guru*** 128255 points
    I should have added this in to my post as well, you see our comprehensive app note for NFC Reader/Writer which includes the download link for the full SLOA227 NFC stack here: www.ti.com/.../sloa227
  • 0 in reply to nick crljenica27
    TI__Guru*** 128255 points
    Hello Nick,

    Can you clarify what further explanation I can offer regarding this issue?