• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 16 subscribers
  • Views 584 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.

SLAA512 -NFC_State stuck in state SENSE_STATE because NFCTargetProtocol register always 0xC0 instead of 0xC5

Christoph Speck
Intellectual 385 points
Other Parts Discussed in Thread: TRF7970A, MSP430F5529

I have just ported the SLAA512 to our hardware.

The firmware successfully handles the POWER_OFF_STATE in NFCTarget_statemachine()  but then the NFC_State remains in SENSE_STATE because the Radio_Wait_IRQ() expects the NFCTargetProtocol register to become 0xC5. When I bring an Android Samsung Galaxy S4 mini nearby the register becomes 'only' 0xC0.

  • 0
    TI__Expert 3550 points

    Hello Christoph,

    For card emulation I would recommend using the example project included in the Card Emulation App note (www.ti.com/lit/pdf/sloa208) . This supports emulating T4TA or T4TB.

    The NFCTargetProtocol has '0xC0' when it receives a SENS_REQ (0x26) NFC-A polling command. The phones send the following polling commands sequentially:

    1 - ATR_REQ (NFC_A) Active P2P
    2 - ATR_REQ (NFC_F) Active P2P
    3 - SENS_REQ (NFC_A)
    4 - SENSB_REQ (NFC_B)
    5 - SENSF_REQ (NFC_F)
    6 - INV_REQ (ISO15693)
    7 - Listen Mode
    Back to step 1

    At the moment your project is getting stuck when the SENS_REQ is received. The TRF7970A would have to be reset to receive the SENSB_REQ. The transceiver driver in the app note SLA208 has been tested extensively and is more robust than the transceiver's driver in the SLAA512 app note.

    I hope this helps!

    Best regards,

    Erick M.

  • 0 in reply to Erick Macias
    Intellectual 385 points

    Hello Erick

    I followed your recommendation and downloaded SLOA208. While porting this code to our hardware I encountered the following problems:


    1) The call of ISODEP_sendPPS_REQ() can not be resolved by the linker because the function is undefined. (declared in iso_dep.h)

    2) In file iso_dep.c, in function ISODEP_init() there are mysterious hardware port access (P4OUT |= BIT2; and P4OUT &= ~BIT2). IMHO: It is quite puzzling to find such code in the midst of a protocol stack. From launch pad and boosterpack documentation I learned that it must be the spi slave select line. I recommend to use the SLAVE_SELECT_HIGH or SLAVE_SELECT_LOW from mcu.h instead. Could you please reassure that my assumption is right ?

    Best Regards,

    Christoph

  • 0 in reply to Christoph Speck
    TI__Expert 3550 points

    Hello Christoph,

    The P4OUT |= BIT 2 and P4OUT &= ~BIT2 were used for debugging on the MSP430F5529 EXP board, so they can be commented out.

    In card emulation you dont need the  ISODEP_sendPPS_REQ() function. That function is needed for reader mode code. If you comment it in the header file, does it remove the build errors?

    Best regards,

    Erick

  • 0 in reply to Erick Macias
    Intellectual 385 points

    Hello Erick


    Just commenting the declaration in the header file is not enough but I commented also the call to the function.

    Now I can compile and download to our hardware. But regretfully it is not working.

    On the signal lines I see a short communication between the MCU and the TRF7970B every 495 ms.

    When I bring my Samsung Galaxy S4 mini near the antenna there is heavy communication on the lines.

    I have ported the NFC p2p sample which is working on our hardware. From this sample I know, that the phone should vibrate when a connection is established. But with this SLOA208 there is no reaction on the phone.

    Do you have an idea how to proceed?


    Best Regards,

    Christoph

  • 0 in reply to Christoph Speck
    Intellectual 385 points

    I did some mistake when porting the SLOA208 code to our hardware.

    The code runs fine now.

    Thanks to Erick.