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.

CCS/TRF7970A: Active P2P communication not switching to 424kbps

Part Number: TRF7970A
Other Parts Discussed in Thread: CC1201

Tool/software: Code Composer Studio

Hi,

i have an active connection P2P with two MSP432P401R Launchpad and two TRF7970A Boosterpack.

It seems like the GUI is showing the current communication at 424kbps but if i debug the code in one MSP432P401R i see on the struct that the current communication speed is at 212kbps:

Is this a GUI bug? Why is the communication not going for 424kbps?

  • Hello Michael,

    I don't remember how the GUI is setup for that case honestly, but looking at the code, it looks like there is a small bug in it possibly:

    				if(sTRF79x0Status.sInitiatorMode.bits.bActiveTypeF == 1)
    				{
    					if(sTRF79x0Status.sInitiatorPayloadFrequency.bits.b212kpbs)
    					{
    						g_sNfcStatus.sP2PCommCurrent.bits.bActive212kbps = 1;
    					}
    					else if(sTRF79x0Status.sInitiatorPayloadFrequency.bits.b212kpbs)
    					{
    						g_sNfcStatus.sP2PCommCurrent.bits.bActive424kbps = 1;
    					}
    				}

    The if and else if statements are identical here. I think the idea was to use b424kpbs?

    Oddly the same would apply to passive P2P.

    Anyways, the connection should be running at 424kbps (also how have I only just now noticed our typo in the structure?), but the variable in the controller just didn't get updated right.

    All this said... we do not recommend the use of Active P2P over Passive P2P. Active was always fairly unstable and difficult to get working across other NFC devices. There are also last I checked no tests offered by the NFC forum to validate Active P2P operation due to that. We strongly recommend the use of Passive P2P instead as it is substantially more robust.

  • Yes i saw early the bug and i had already fixed it and also add the if statement missing in the polling function. Now i can enable only 424 kbs for target and initiator and it works.

    I intend to use NFC P2P active at 424kbs only between the two devices TRF7970A. I dont want to be compatible with other devices.

    Will the connection between two TRF7970A at active 424kbs always be stable? Is there any Software issue on the NFC stack?

    Best regards,

    Michael

  • Hello Michael,

    Software wise there shouldn't be issues, but the problem is more from a general hardware level to make a robust system due to how Active P2P works.

    Lets start with the basics first.

    Why do you feel you need Active P2P? What are your requirements and how does Active solve them better than Passive?

  • Hi Ralph,

    my goal is to send data over the air and on both sides i have supply voltage.

    As faar as i understood passive is wenn the target doesnt have supply voltage and gets its power from the NFC field right?

    I want to send UART data with 230,4 kbps from target to initiator from both sides and thats the reason i want to use 424kbps.

    What do you think?

  • Hi Ralph,

    so i notice that i cannot reach the data rate of 424kbps.

    Below you see our code in main and we are sending data without the GUI on the PC and measuring a GPIO to see how fast can he send the data and how many packages can be send out.

    • If we send 1 Byte than it takes around 14ms to resend the next byte. 
    • If we send 125 Bytes it takes around 16.3ms to resend the next 125 bytes
    • If i send more than 125 bytes the NFC state changes and doesnt stay at NFC_DATA_EXCHANGE_PROTOCOL

    I made the test on one direction and on both directions and they worked only at maximum 125 bytes.

        while(1)
        {
            eTempNFCState = NFC_run();//Listening oder Polling
    
            if(eTempNFCState == NFC_DATA_EXCHANGE_PROTOCOL)
            {
    
                if(NFC_P2P_getModeStatus(&sP2PMode,&sP2PBitrate))
                {
                    counter_NFC_P2P_getModeStatus++;
                    //
                    // Read the receive status structure - check if there is a received packet from the Target
                    //
                    sP2PRxStatus = NFC_P2P_getReceiveState();
                    if(sP2PRxStatus.sDataReceivedStatus != RECEIVED_NO_FRAGMENT)
                    {
                        //UARTSend((uint8_t *)sP2PRxStatus.pui8RxDataPtr,sP2PRxStatus.ui16DataReceivedLength);//TODO fixme
                    }
                }
    
                GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0, GPIO_PIN_0);//LED
            }
            else
            {
                GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0, 0);//LED
            }
    
            // Update Current State if it has changed.
            if(eCurrentNFCState != eTempNFCState)
            {
                if(eCurrentNFCState != NFC_TARGET_WAIT_FOR_ACTIVATION
                    && eCurrentNFCState != NFC_STATE_IDLE
                    && (eTempNFCState == NFC_PROTOCOL_ACTIVATION
                    ||  eTempNFCState == NFC_DISABLED))
                {
                    eCurrentNFCState = eTempNFCState;
    
                    // Initialize IDs for NFC-A, NFC-B and NFC-F
                    NFC_initIDs();
    
                    ui16BytesReceived = 0;
                    ui32PacketRemaining = 0;
                }
                else
                {
                    eCurrentNFCState = eTempNFCState;
                }
            }
    
            if(g_ui16BytesReceived==0)
                g_ui16BytesReceived=125;//here maximum bytes i can send at one, why not more?
    
            // Check if any packets have been received from the NFC host.
            if(g_ui16BytesReceived >0 || g_ui16BytesSize > 0)
            {
                Serial_processCommand();
            }
        }
    }
    
    
    void Serial_processCommand(void)
    {
        uint8_t ui8FragmentLength;
    	
        ui8FragmentLength = SNEP_getTxBufferStatus();
    
        if((uint32_t) ui8FragmentLength > g_ui16BytesReceived)
        {
            ui8FragmentLength = (uint8_t) g_ui16BytesReceived;
        }
        if(SNEP_setupPacket(&g_ui8SerialBuffer[0], g_ui16BytesReceived,ui8FragmentLength) == STATUS_SUCCESS)//Is this function the right one or should i use a different one?
        //if(NFC_P2P_sendNdefPacket(&g_ui8SerialBuffer[0],first,ui8FragmentLength,g_ui16BytesReceived) != 0) 
        {
            memset(&g_ui8SerialBuffer,0,g_ui16BytesReceived);
            g_ui16BytesReceived = 0;
            GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_3, 0);
        }
        else//Failed cannot add data do queue anymore, i am busy
        {
            GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_3, GPIO_PIN_3);
        }
    }

    Here is the screen shot measuring GPIO_PIN_3 and you can see the time that it takes to resend the next bytes (both directions are sending 125 bytes) 

    Here is our NFC configuration maybe we need to set something else here?

    //*****************************************************************************
    //
    //! NFC_configuration - Handles the initial NFC configuration.
    //!
    //! Setup all NFC Mode Parameters.
    //!
    //! Current modes enabled: Card Emulation
    //! Current modes supported: Card Emulationa and Peer 2 Peer
    //! Reader/Writer is NOT supported yet.
    //!
    //*****************************************************************************
    
    void NFC_configuration(void)
    {
        g_sP2PSupportedModes.ui8byte = 0x00;
        g_sP2PSupportedTargetBitrates.ui8byte = 0x00;
        g_sP2PSupportedInitiatorBitrates.ui8byte = 0x00;
        g_sP2PSetupOptions.ui8byte = 0x00;
    
        // Set the TRF7970 Version being used
        g_eTRFVersion = TRF7970_A;
    
        // External Amplifer (disconnected by default)
        g_bExtAmplifier = false;
    
        // Configure TRF External Amplifier for the transceiver
        TRF79x0_setExtAmplifer(g_bExtAmplifier);
    
        // Configure TRF Power Supply (5V = true, 3V = false)
        g_bTRF5VSupply = false;
    
        // Configure TRF Power Supply
        TRF79x0_setPowerSupply(g_bTRF5VSupply);
    
        // Milliseconds the NFC stack will be in listen mode
        g_ui16ListenTime = 500;//500
    
        // Set the time the NFC stack will be with the RF field disabled (listen mode)
        NFC_setListenTime(g_ui16ListenTime);
    
        // Enable (1) or disable (0) the Auto SDD Anti-collision function of the TRF7970A
        g_bEnableAutoSDD = 0;
    
    
        // Enable Peer 2 Peer Supported Modes
        g_sP2PSupportedModes.bits.bTargetEnabled = 1;
        g_sP2PSupportedModes.bits.bInitiatorEnabled = 1;
    
        // Set P2P Supported Bit Rates - Target mode
        g_sP2PSupportedTargetBitrates.bits.bPassive106kbps = 0;
        g_sP2PSupportedTargetBitrates.bits.bPassive212kbps = 0;
        g_sP2PSupportedTargetBitrates.bits.bPassive424kbps = 0;
        g_sP2PSupportedTargetBitrates.bits.bActive106kbps = 0;
        g_sP2PSupportedTargetBitrates.bits.bActive212kbps = 0;
        g_sP2PSupportedTargetBitrates.bits.bActive424kbps = 1;
    
        // Set P2P Supported Bit Rates - Initiator mode
        g_sP2PSupportedInitiatorBitrates.bits.bPassive106kbps = 0;
        g_sP2PSupportedInitiatorBitrates.bits.bPassive212kbps = 0;
        g_sP2PSupportedInitiatorBitrates.bits.bPassive424kbps = 0;
        g_sP2PSupportedInitiatorBitrates.bits.bActive106kbps = 0;
        g_sP2PSupportedInitiatorBitrates.bits.bActive212kbps = 0;
        g_sP2PSupportedInitiatorBitrates.bits.bActive424kbps = 1;
    
    
        // Certification Config Start //
    
        // Enable (1) or disable (0) Wave 1 NFC Forum Certification functionality
        // Note: Enabling this feature can affect interoperability with NFC Devices that are not certified.
        g_bSupportCertification = 0;
    
        // Allows for Customization of the DID (Device Identification) number when in initiator mode
        g_ui8NfcDepInitiatorDID = 0x00;
    
        // Enable LLCP
        g_sP2PSetupOptions.bits.bP2PSupportLLCP = 1;
    
        // Enable Loopback
        g_sP2PSetupOptions.bits.bP2PSupportLoopback = 0;//Zum debuggen
    
        // Specify maximum number of timeouts and protocol errors allowed before resetting
        g_sP2PSetupOptions.bits.ui3P2PMaxTimeouts = 10;//2
        g_sP2PSetupOptions.bits.ui3P2PMaxProtocolErrors = 10;//2
    
    
        // Configure Peer 2 Peer functions for the correct modes and communication bitrates
        NFC_P2P_configure(g_sP2PSupportedModes,g_sP2PSupportedTargetBitrates,g_sP2PSupportedInitiatorBitrates);
    
        // Configure NFC DEP functions including passing the DID
        NFCDEP_configure_P2P(g_sP2PSetupOptions,g_bSupportCertification,g_ui8NfcDepInitiatorDID);
    
        // Set the Auto SDD flag within nfc_a.c
        NFC_A_setAutoSDD(g_bEnableAutoSDD);
    
        // Set the current TRF version within trf79x0.c
        TRF79x0_setVersion(g_eTRFVersion);
    
        // Set Certification Support for all Protocols - Required for NFC Forum Certification
        NFC_setSupportCertification(g_bSupportCertification);
    
        // Set Test Enable flag within trf79x0.c - Required for NFC Forum Certification
        TRF79x0_testFlag(g_bSupportCertification);
    }

  • Hello Michael,

    Michael Liesenberg85 said:
    As faar as i understood passive is wenn the target doesnt have supply voltage and gets its power from the NFC field right?

    That is not true at all.

    I would recommend you read our app note for full details, but I will explain some here. Here is the app note by the way: http://www.ti.com/lit/pdf/sloa192

    Passive P2P is where only one NFC device creates the RF field - the initiator. The target device does not generate an RF field. However, we have not put together a system where the TRF7970A and Host MCU are both powered by the RF field. In all Passive P2P applications, both Initiator and Target TRF7970A's are powered with a supply voltage like your use case would be.

    Based on your description, you absolutely should be using passive P2P.

    Active P2P's only advantage is trying to stretch communication range, but most of the time it performs too poorly at longer ranges to be viable anyways.

    Michael Liesenberg85 said:
    I want to send UART data with 230,4 kbps from target to initiator from both sides and thats the reason i want to use 424kbps.

    So you are expecting around ~30kBytes/s over the air then?

  • Michael Liesenberg85 said:

    so i notice that i cannot reach the data rate of 424kbps.

    424kbps is over the air. That is not total transfer time. There is overhead to send data. Highest data rate we measured between two TRF7970A's IIRC was ~35kByte/s but I don't remember if that was passive P2P @ 424kbps or R/W & Card Emulation @ 848kbps. I think for P2P, 30kBytes/s is doable.

    Michael Liesenberg85 said:
    • If we send 1 Byte than it takes around 14ms to resend the next byte. 
    • If we send 125 Bytes it takes around 16.3ms to resend the next 125 bytes
    • If i send more than 125 bytes the NFC state changes and doesnt stay at NFC_DATA_EXCHANGE_PROTOCOL

    I made the test on one direction and on both directions and they worked only at maximum 125 bytes.

    That is expected. If you send more than 125 bytes - it has to send through multiple cycles.

    The TRF7970A has a FIFO that is 127 bytes in size. Two more bytes are needed for packet overhead. So the packet gets divided when more than 125 bytes are being sent. This is exactly how the device must operate.

  • Hi Ralph,

    thank you very much for your answer.

    Since i cannot reduce the 15ms time to resend data, i dont think the TRF7970A is suitable for my application than.

    I can do the protocoll on the MCU myself and i dont need to be compatible with other devices on the market. Do you know any transceiver i can use from TI?

    My goal is to use a frequency that is worldwide allowed. The lower the frequency the better is it to integrate to the application i think.

    Maybe CC1201 looks like it can go up to 1250kbps and works with many different frequencies?

    How low can the freuqency go? Does it work also with 13.567 / 27.283 / 40.66 MHz?

    Best regards,

    Michael

  • Hello Michael,

    Michael Liesenberg85 said:
    I can do the protocoll on the MCU myself and i dont need to be compatible with other devices on the market. Do you know any transceiver i can use from TI?

    You should be able to reduce the time then but I am not sure by how much. However, we are not in position to support a proprietary application like that at any level and it would not be trivial so I wouldn't recommend trying. That's likely going to be a weeks level task rather than days to unravel the NFC stack but retain proper error handling etc. - especially with no prior knowledge.

    As for other devices, I am only knowledgeable about NFC. I have no idea what the CC1201 or other devices are capable of. I would recommend you make a new E2E post for that query so the right team who does have knowledge can handle it.

  • Hi Ralph,

    is there a way to use the TRF7970A chip with my own stack?

    I want to be able to do my own low level stack only to send 1 byte as quick as possible with no overhead.

    Is there a way to do this or the internal TRF7970A firmware wont work that way and need a ISO selection?

    Is there any NFC chips that are very dummy and i can just write and read a byte with my own stack? 

    Edit:

    I saw that i can use the Direct Mode 0 and do my own modulationsending my data on MOD PIN and on the other side reading on IO_6?

    Is there any example code on how to use it?

    How would i simple do this on the MCU side? I could use a second SPI and connect MOSI on MOD PIN and send 8 Bit easily on SPI with a 1MHz clock maybe?

    On the receive Part maybe use a timer to check the IO_6 state, high or low?

    Best regards

    Michael

  • Hi Michael,

    You absolutely could use the device with your own stack, it's just not something we'd support really if you run  into issues.

    Michael Liesenberg85 said:
    I want to be able to do my own low level stack only to send 1 byte as quick as possible with no overhead.

    All you need to do then is:

    1) Configure the registers for the communication modulation & data rate you want to use in addition to basic config (like power setting etc.)

    2) Make sure your target device uses the same for receiving data

    3) Turn your initiator side RF field

    4) Send the byte either with or without CRC.

    From there, you'd get a TX complete on your initiator, and an RX interrupt on your receiver for the one byte which would be able to be read from the FIFO immediately. 

    Complexity comes with making sure packets aren't lost or communicating how much to expect etc.

    If you aren't worried about data loss, then it is actually very simple. Especially if it's a one way channel only.

    Michael Liesenberg85 said:
    Is there a way to do this or the internal TRF7970A firmware wont work that way and need a ISO selection?

    The ISO selection in Register 0x01 is just to tell the device how the AFE should handle the modulation scheme and transmission.

    Michael Liesenberg85 said:
    Is there any NFC chips that are very dummy and i can just write and read a byte with my own stack? 

    I would say ours would be a good fit as most 'black box' chips have the NFC layer wrapped around that you don't want.

    Michael Liesenberg85 said:
    I saw that i can use the Direct Mode 0 and do my own modulationsending my data on MOD PIN and on the other side reading on IO_6?

    For what you are doing, that would be the equivalent of using a wrecking ball to hammer a nail in place.

    Yes it's possible and we have some example code but DM0 is very complicated and probably would add processing time that would take longer than using Direct Mode 2. You have to have your MCU run at 13.56MHz and manually decode the bitstream via software algorithms to unwrap the modulation and extract data. Not at all speed efficient, but a way to get around official protocols. I don't think even if you could up the over-the-air data rate (I have zero idea if that's even feasible, I doubt it is but...) you'd still likely lose all those gains on trying to demodulate the received data.

    Stick with Direct Mode 2 for this :)