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.

P2P API (reference design) works only when target and initiator are enabled (passiv)

Other Parts Discussed in Thread: TIDM-NFC-P2P, TRF7970A

I really much appreciate the reference design published by TI under the link:
http://www.ti.com/tool/TIDM-NFC-P2P?CMP=AFC-conv_DS5Ref

I ported the code to a different processor and I am able to send and receive messages using my Android Galaxy S4 mini, Version 4.2.2. On the phone I use the "NDEF Tools for Android" App. It works as long as Target and Initiator mode are enabled (only passiv)

My idea was to use SNEP. The phone shall initiate the communication, send a get request that should be answered by the TRF7970. For this I disabled the initiator mode in the sample standalone application. The phone still vibrates when the TRF7970 is placed nearby but no data is transfered anymore.


Is there a limitation of the API that requires all the time both modes?

Is there the intention to create a library for the TRF7970A such as the simple link library for CC3xxx Wifi chip? Then proper versioning would be required.

  • Hello Christoph,

    The NFC stack should be able to run in both of the scenarios you described. When both target and initiator modes are enabled the stack will be switching between both polling and listening modes until a connection is established. When only one mode is enabled the code will stay in that mode until the connection is established.

    When you disabled the initiator mode in the sample app, and the phone vibrated a connection was established between the handset and your system. For SNEP did you implement the Get SNEP command, or are you referring to a PUT command being sent from the handset to the system with a message that requests a response?

    When no data is being transferred, does this mean that the phone is vibrating when the TRF7970A is nearby and you are clicking on the screen to send a message from the phone but it is not being successful? Or is the message going through, and the stack is not informing you that a message has been received?

    It would be helpful if you took an logic signal analyzer screenshot of the SPI lines (MOSI, MISO, CLK, Slave Select) and IRQ, to further debug what commands are being exchanged between the standalone stack and the handset. We have a macro decoder for the TRF7970A, using the .csv output of the Saleae' SPI analyzer. For more information visit www.saleae.com.

    We are in the process of creating a standalone stack that will support the three NFC modes (P2P, CE, RW).

    Regards,

    Erick M.

  • Hello Erick


    Thank you for you prompt reply. It's good to know, that the connection has been established when the phone vibrates.

    You asked if I implemented the SNEP GET command. Do you mean on the Android phone or in the sample API code? On the phone in the original App the POST request was used. I asked the Android programmer (on the other side of the world) to use the GET request instead. But both Applications behave the same way (no data transfer) when TRF7970A has only target mode enabled. The TI sample code is unchanged. I hoped to receive the text from the phone and then send back the answer. In "snep.c" I have seen several cases for SNEP_REQUEST_GET with no implementation and wondered if I would have to add code there. There is also the SNEP_RESPONSE_NOT_IMPLEMENTED which may be an indication that this would not work.


    Whether the message is comming through or not, that I can not say currently. The stack does not inform me about it (as it would, when initiator mode would be enabled). I would have to check with a logic analyser as you proposed. I do not see the point but it would give us additional information.

    This maco decoder you talk about. Is this to autmatically analyze and find errors where NFC standards are hurt or is it just to show TRF7970A register settings? Would it help if I would export and send you the SPI communication?

    Good to know, that you work on a standalone stack. When do you expect to release it?

    What would you propose if I intend to exchange a couple of bytes between a device with TRF7970A and a phone. We invested a lot of time and dumped the idea to switch the TRF7970A into card emulation mode. Emulating a mifare ultra light card was not successfull (device was not recognized by Android). We are much closer now with the p2p.

  • Hello Christoph,

    The macro decoder decodes the data into TRF7970 specific writes/read and further decodes the data being sent over the air based on NFC specs. Please see below for the format of the unmodified csv file (SPI output) and the format after running the decoder.

    6521.Test 1.csv

    5355.Test_Decoded.xlsm

    Please send the SPI communication in the same format as shown in the unmodified .csv and I'll be able to see if the phone is trying to send data and why is not going through.

    To exchange a few bytes back and forth between the TRF7970A and a handset, you are using the correct software.

    Hope this helps 

  • Hello Erick


    That sounds good.

    I would have to convert my file:

    time, channel bits for 8 channels
    ....
    4115127061,00010000
    4115127086,10010000
    ; trace text,MOSI,01
    ; trace text,MISO,02

    Into your format: time; packet; MOSI; MISO

    Has the time column to be specified in seconds?

    What is the packet number, from what can I derive this?

    Best Regards,

    Christoph

    Would it be beneficial to wait until your library is available?

  • Hello Christoph,

    The library will be based on the same functionality the P2P reference design currently has; therefore, I recommend we continue to debug the current system.

    The time column is in seconds.

    The packet number is each SPI transaction (typically 2 bytes when reading a single register, or more than 2 when reading / writing the FIFO) from the falling edge to the rising edge of the Slave Select.

    Best regards,

    Erick M.

    Best regards,

    Erick M.

  • Hi Erick

    How do you expect me to upload the *.csv files? Regrettfully this type is not allowed to attach in this forum.