• State TI Thinks Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 3 answers
  • Subscribers 17 subscribers
  • Views 1930 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.

14443A Select no response (TRF7970EVM, DLP-RFID2)

devWarrior
Intellectual 330 points
Other Parts Discussed in Thread: MSP430F5529, MSP430G2553, TRF7970A, MSP430F2370

Hi,

I'm trying to get the DLP-RFID2 to write to an android phone (Nexus 5, and s7 edge for testing). Android uses the 14443A protocol, and everything works up until the SELECT command. I've tried the TRF7970EVM Control GUI and the same thing happens. No response after the SELECT command. Attached is my Salae capture when writing from my microcontroller. I'm following the steps in the TRF7970EVM User's Guide, so I'm guessing it might be the way Android NFC communicates? Any help would be greatly appreciated!

14443a_android(select_problem).logicdata.zip

  • 0
    TI__Guru*** 128085 points
    Hi Dev,

    I don't know how to interpret that data, we didn't make that module so it's not something I have a lot of knowledge with.

    Are you trying to do an ISO14443 Select like a 0x93 0x20? Or is that an NDEF Application Select?
  • 0 in reply to Ralph Jacobi
    TI__Guru* 90906 points

    Looks like he is using the host commands from GUI. if you look at the data in ASCII and HEX in the Saleae GUI...

    his MCU is acting like the EVM GUI - this is what he is trying to do - it looks like to me

    you can see it is printing out the UART responses, just like the GUI does with the TRF79xxAEVMs

    @ Dev - i think you should use the TRF7970A BoosterPack and an MCU platform (like MSP430G2553 or MSP430F5529) - its more straightforward if you are doing something truly embedded. There are better code examples for reading the handset at least this way

    and, since the handset tag is not using NFC (it's using HCE), and switching between Type A and Type B, when its a card), you need more support than what the firmware on that module supports anyway.

     

  • 0 in reply to Josh Wyatt
    Intellectual 330 points

    I was previously using the TRF7970A boosterpack with my own MCU and we got our project to the point where it was ready to put into a PCB. The problem was that we can't use an MSP430 in our project, and the only surface mount module that had it's own antenna was the DLP-RFID2. After getting through the many issues with the DLP-RFID2, I got it to work with iso14443B tags. Anyways, back to my issue:

    I have the Android phone emulating a tag. Are you saying the TRF7970A doesn't support HCE emulating NFC?

    Even when I try to read a normal iso14443A tag, the select command doesn't receive a response. Am I doing the the 14443A protocol correctly according to the TRF79xxAEVM??

  • 0 in reply to devWarrior
    TI__Guru*** 128085 points
    Hello dev,

    The TRF7970A definitely supports HCE emulation on a chip level, but the DLP-RFID2 is controlled by an MCU that uses a set of host commands and that limits the control you have of the TRF7970A to handle such applications.

    The TRF7970A is a transceiver which will send and receive commands based on the MCU controlling it. As long as it supports the over-the-air communication (ISO14443, ISO15693 etc.), then it can interact with any device as long as it replies quickly enough. HCE uses ISO14443A and ISO14443B, and the timing requirements are no problem for a TRF7970A + MCU to meet. So it can support HCE with the right firmware. Josh and I just both doubt the DLP-RFID2 firmware will be sufficient.

    It might be possible to do with the custom raw write commands, but it would take a lot of effort to design this - and I can't guarantee it will work. I'm not familiar enough with the details of how fast those custom commands can be sent and processed by the DLP-RFID2 to know if it will be able to meet the timings of the NFC phone which will timeout if the communication isn't fast enough.
  • 0 in reply to Ralph Jacobi
    Intellectual 330 points
    Ok, that makes sense. I still need to get it communicating with a normal 14443A tag, which has the same issue. After reading a different document, I see that I have to send a CRC at the end of my SELECT command which I wasn't doing. How do I calculate the CRC, and which bytes am I calculating it for?
  • 0 in reply to devWarrior
    TI__Guru*** 128085 points
    Hello dev,

    You shouldn't need to Calculate the CRC. The TRF7970A can do this for you. You either transmit with CRC or without CRC.

    When you say SELECT command, do you mean the 0x93 0x70 command?

    Is the document you are reading from TI, or somewhere online you can link? I want to make sure we are on the same page on the command in question.
  • 0 in reply to Ralph Jacobi
    Intellectual 330 points

    I'm reading the TRF7970A Firmware Description (http://www.ti.com/lit/an/sloa157/sloa157.pdf). The DLP-RFID2 works just like the TRF7970EVM

  • 0 in reply to devWarrior
    TI__Guru*** 128085 points
    Hi dev,

    I never developed any of the TRF7970AEVM firmware, so I wasn't aware of how it seems to be setup. I'm not entirely sure what the purpose of that 0xA2 select command is to be honest. I went through the firmware flow, and it makes no logical sense, as it doesn't appear to do anything... so then I also used a TRF7970AEVM +GUI and sniffed the over the air communication, and basically confirmed that the Select command there does not do anything productive. Why it exists is a mystery to me right now...

    Anyways, from your application standpoint, the Anticollision function should be sufficient to get you past the initial tag selection. I confirmed with over the air sniffing that it does go through all tag detection and selection processes and returns the SAK as the final data string over the air. Unfortunately, it does not look like the firmware is setup to feed the SAK response back up to you though :(

    The SAK would be useful for knowing if the tag you present is ISO14443-4 compliant, but if you anticipate only needing to support ISO14443-4 compliant tags (such as Android HCE), then you can just proceed on with your commands. It's only important to know if you plan both compliant and non-compliant tags with the same project.
  • 0 in reply to Ralph Jacobi
    Intellectual 330 points
    Ok, that makes more sense. Thanks for your help. Do you happen to have any logic analyzer captures of your TRF7970EVM writing to a 14443A tag? Maybe I could try and copy what you do, and hopefully get it to work
  • 0 in reply to devWarrior
    TI__Guru*** 128085 points
    Hi dev,

    Unless Josh has something for writing to an ISO14443A tag with the EVM GUI, that doesn't exist to my knowledge. The read/write functionality for ISO14443A is absent in the GUI and can only be done through the use of Send Raw commands via the Test tab.

    That said, I could provide some general TRF7970A captures for writing to an ISO14443A tag. If you want that, I can send you that for either Type 2 or Type 4A tags. Type 2 being not ISO14443-4 compliant, and Type 4A are ISO14443-4 compliant and is what Android HCE would be.
  • 0 in reply to Ralph Jacobi
    Intellectual 330 points
    Type 4A would be really helpful. I have Type B communication working (reqb, attrib, and the raw commands), I just wasn't sure which commands I needed to send before sending raw. Just reqa?
  • 0 in reply to Ralph Jacobi
    TI__Guru* 90906 points

    0xA2 in that code is for Type 2 NFC tags, for writing one block of myD move (from Infineon)
    0xA1 in that code, is for writing two blocks of myD move (from Infineon)

    As I stated before and Ralph reiterated - HCE is not NFC, it is ISO14443A (or B 1/2 the time), and Layer 4 compliant, which means (for A, if you insist on only using that) you must go through the anti-collision process for the ISO14443A, send RATS, send PPS (optional), send HCE tag application select, select the file header, then read or write the binary from it, then select the file itself, read the length, then read the binary for the contents or write it.

  • 0 in reply to Josh Wyatt
    TI__Guru*** 128085 points
    Josh,

    Agreed on the Type 2 codes. In this case, we were talking about a Host Command code on the MSP430F2370 side though, nothing to do with RFID/NFC commands haha.

    dev,

    I can get a capture of an NFC process for you which includes application select and read binary etc. - but as Josh said, HCE will differ from that a bit. However it should give you a very solid starting point. You would just need to change items like the parameters of the application select and possible file header.

    From a host command standpoint, if you use the Anticollision with either REQA or WUPA, then the module will you through to the point you'd issue a RATS commands. I'll try and mark that point on the capture when I get it later today.
  • 0 in reply to Ralph Jacobi
    TI__Guru*** 128085 points

    Hi dev,

    I got a capture you can look at for this. If it loads right for you, two markers should frame the communication aspects you will need to construct on your end.

    Type4A_NDEF_Select_Read.logicdata

    Hope this helps!