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: Communicating with Android

Part Number: TRF7970A
Other Parts Discussed in Thread: DLP-7970ABP

Hello,

I just wanted to know if it was possible to communicate with android phones using the TRF7970A?

I am attempting to just send the ISO7816 Select File command; but the TRF is not picking up the response from the phone.

I've written an app for this and tested with a different NFC controller/antenna and it works perfectly with 4 different android phones.

Are there specific registers that need to be configured for this, because the system I'm developing in is used to communicate with DESFire cards (which work perfectly), and I've configured the TRF registers accordingly?

Thank you

  • Update:

    So, I just used the NFC TI tool with a connected DLP-7970ABP and I was able to detect the android phone. So, I'm assuming that the ISO14443A 3 & 4 are being executing successfully. The FW I have written also succeeds with these two processes. Where it's failing is receiving response data to the initial ISO7816 Select File command. Below is the code I've written for that specific command:

    uint8_t Iso7816Commands__IsoSelectFile(uint8_t p2, uint16_t fileId, uint8_t *dfName, uint8_t dfSize)
    {
       uint8_t status = ERROR;         /* Initialize return status */
       uint8_t bufSize = 0x00;            /* Number of bytes to be transmitted to TRF FIFO */
       uint8_t *buf = nfc_data.buf;      /* TRF FIFO data buffer */
    
       buf[bufSize++] = 0x8F;
       buf[bufSize++] = 0x93;  /* Delayed transmit with CRC */
       buf[bufSize++] = 0x3D;
    /* Calculate the number of bytes the TRF has to send to the tag */ uint16_t numBytes = 0x0006 + dfSize; buf[bufSize++] = (uint8_t) ( numBytes >> NIBBLE ); buf[bufSize++] = (uint8_t) ( ( 0x000F & numBytes ) << NIBBLE ); /* ISO/IEC 7816-4 C-APDU (Command Application Protocol Data Unit) */ buf[bufSize++] = 0x00; /* Standard ISO/IEC 7816-4 Command CLA must be 0x00 */ buf[bufSize++] = ISO_SELECT_FILE_CMD; /* 0xA4 */ buf[bufSize++] = 0x04; /* Select file using DF Name */ buf[bufSize++] = p2; buf[bufSize++] = dfSize; /* Length of data field */
    /* Populate Data Field & update the buffer size */ memcpy(&buf[bufSize], &dfName[0], dfSize); bufSize += dfSize; buf[bufSize++] = LE; /* Expected response length - 0x00 = All available data */ /* Transmit Command */ Trf797x__RawWrite(&buf[0], bufSize); HAL_Delay(5); /* Wait for ISO/IEC 7816-4 R-APDU (Response APDU) response from tag */ /* Timeout = 26 ms */ WaitRxData(0x1A); HAL_Delay(5); /* Check if response arrived */ if( Trf797x__GetState() == TRF797X_STATE_RX_COMPLETE ) { sprintf(printBuf, "UID: %02X %02X %02X %02X %02X %02X %02X\r\n", buf[0], buf[1], buf[2], buf[3], buf[4], buf[5], buf[6]); printDebug(printBuf); } else { sprintf(printBuf, "ISO Select File Command error: %02X\r\n", Trf797x__GetState()); printDebug(printBuf); } return status; }

    The issue ^ is that the response in never received.

     

  • Hello Wilmer,

    Glad you were able to try out the TI NFC Tool and see the device is capable of communication with NFC tags

    In general we do not support re-making that level of NDEF handling because we spent a large amount of development effort & debug to provide this including testing vs NFC standards. I can give a pointer or two maybe, but we are not going to re-invest time as the TI NFC Stack works properly and should be used as is for such an application.

    You should very strongly consider porting the DESFire work you have done as an additional application into this. It was not clear when you had asked about DESFire in the past that you later needed full NFC functionality or I may have advised you take these steps earlier on. If you need to add other NFC protocols (Type 2/3/5), this will absolutely save you work in the long run than re-doing the stack. We spent months on developing the Reader/Writer mode stack.

    The stack would be able to support proprietary tags as well with APIs such as ISO_7816_4_sendAPDU and ISO_7816_4_getWriteAPDUStatus.

  • Hello,

    I am attempting to do this on my own system. The system needs to only support ISO 14443A type tags. I just used the TI NFC Tool to validate that detection of an android phone is possible with the TRF7970A. Using the FW I have written, I am able to send the command shown above to various DESFire cards and I'm capable of receiving a response. I'm just wondering what the reason could be that the when I try with an Android, the TRF does not pick up the response. The app I've written for it was tested and is working as it should using a different RFID transceiver.

  • Hello Wilmer,

    Did a quick check vs one of our easier to read examples and you are missing the I-Block PCB + Block Bit Number byte.

    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++] = 0x80; // 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++] = 0xA4; // INS = Select (File in this case)
    g_pui8TrfBuffer[ui8Offset++] = 0x00;
    g_pui8TrfBuffer[ui8Offset++] = 0x0C;
    g_pui8TrfBuffer[ui8Offset++] = 0x02;
    g_pui8TrfBuffer[ui8Offset++] = ((ui16FileID >> 8) & 0xFF);
    g_pui8TrfBuffer[ui8Offset++] = (ui16FileID & 0x00FF);

    Also not sure if delayed transmit works well for you, I always have used Send with CRC via command 0x91.

    Hopefully that missing byte was the gotcha. NDEF is very tricky to get everything right sometimes.

  • Thank you so much!

    It was the PCB byte!

    Where can I find more information about this?

  • Is this PCB byte supposed to be added to the R-APDU as well - in the response sent by the Android device?

    I'm still having trouble on the RX side. Would a different Direct mode need to be configured a long with CRC in the RX response?

  • Hello Wilmer,

    Wilmer Suarez said:
    Where can I find more information about [the PCB byte]?

    That is defined in ISO14443-4, and also elaborated on in the NFC Forum specifications. We referenced the direct specifications, not sure if there are internet resources. If you are developing at this level, getting the specs is invaluable in my opinion.

    Wilmer Suarez said:
    Is this PCB byte supposed to be added to the R-APDU as well - in the response sent by the Android device?

    One of the bytes sent by the response with will a PCB byte. That's something you can use to decode what type of reply you received, for example you may only get an R-Block (R-APDU) in reply rather than an I-Block which contains data. You also need to support S-Blocks for Wait time extension.

    Wilmer Suarez said:
    I'm still having trouble on the RX side. Would a different Direct mode need to be configured a long with CRC in the RX response?

    No, you want to use Direct Mode 2 only. Different Direct modes only help with non-ISO complaint tags.

    What you may need to do is adjust the ISO Control Register for if it looks for an RX CRC or not. That is bit 7 of the register. When you are in Layer 4, everything has a CRC on it. The CRC is sometimes absent for tag detection processes.

  • Thanks so much for your reply. I managed to get it working. It seems like only some phones respond properly though.