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

TRF7970A: How do I use 2 TRF's as a simple serial bridge?

Kyle Blay
Prodigy 130 points
Part Number: TRF7970A

Hi all,

I wish to send small packets of data back and forth between two systems via an NFC link using 2 TRF7970A (TRF) chips (8-32 byte packets, about once every 100 ms).

Both ends are completely known (exact same hardware, C2000 MCUs and the same basic software) and the devices don't have to deal with any 3rd party NFC interfaces at all.

I've spent some time coding up the SPI interface etc. to interact with the TRFs and I've read and re-read the datasheet for it several times, along with a lot of other specification documents for the various layers of 14443A/B and 15639 etc...

It's all very complex, the TRF datasheet is very confusing and it seems to involve lots of issues such as dealing with RF collisions, multiple targets, parameter selection etc.

In my intended (industrial control) application there will only ever be two devices of identical types in proximity to one another, one can always be the initiator, and the other can always be the target, but there needs to be two-way comms (they can be alternating 1-way comms as separate "transactions" separated in time if that's easier. i.e. Initiator Transmits data packet to Target, or Initiator requests data packet from Target)

What I'm looking for is some answers to a couple of questions :)

1/ Is it possible to set up a very simple state machine to send a packet of data to the target leveraging the ISO14443A/B framing features of the TRF without needing to refer to SENS_REQ/SDD/PFA negotiation and slot timings etc?

2/ If I configure both ends exactly the same, except one as initiator and one as target, can I just send a non-ISO fixed-length string of data and have the other end receive it?  I know the TRF embeds some logic for doing the SDD state-machine, and spits out target protocol identification bits - do I need to use this if I'm configured for ISO14443A/B modes or can I just have an IRQ handler that deals with the RX flag (after transmission/reception has completed) and then reads out the data bytes that were sent? I can guarantee that there would be less than 127 bytes transmitted in any one transmission.

3/ Failing all that, has anyone successfully ported the example/reference software stack to a C2000 architecture? I'd have some issues with the busy-waiting nature of the stack (I need to check for received transmissions regularly and then do other tasks with the CPU, it can't be waiting around for 500 ms in listen mode waiting for a potential transmission)... 

Sorry for the vagueness of my questions. I'm after a simple dumb NFC serial connection for a proprietry, not an industry standard NFC P2P or Reader/Writer stack implementation...

What I know I can't do (due to the hardware design) is go into direct mode 0 or 1 and shift the modulation bits in/out in real time - which in hindsight seems like it would have been the best approach :(

Any links, tips or suggestions would be appreciated!

Cheers,

  Kyle

  • 0
    TI__Guru*** 128265 points
    Hello Kyle,

    I understand your application intentions and certainly can agree that the TRF7970A datasheet and the device itself is a complicated topic for an advanced (yet 'simplistic') application such as what you are describing.

    First off, to answer your questions:

    1) For a proprietary system, you don't need to use any of those commands. Timing wise you may need to deal with timeouts.

    2) I don't see why not. The caveat would be you need some sort of way to acknowledge a packet is received, otherwise you'll never know if a packet fails to send. NFC is not flawless communication, if you send 10,000 packets, eventually even in perfect conditions, one will fail eventually. You need to be able to handle these failures.

    3) No we haven't, but it shouldn't be too hard to do so. The porting is mainly GPIO config, MCU specific details (Clocks, Interrupts, Timers), and getting SPI working. As far as the timing of 500ms listen wait, you can change that... that is just the example amount, but you can make that far shorter. I would say at least 25 ms is a minimum though.

    Now then all of that said, we don't really offer support for such an unusual proprietary application. I don't mind giving you this info as guidance points to understand whats possible, but I can't help with the actual implementations.

    We spent a lot of time and energy to make our NFC examples (I presume from your comments you've read SLOA192 for Peer to Peer, if not, check it out) to ensure the device is used correctly based on it's intended use case (as an NFC device, and not a raw transceiver), so if you opt to pave your own road forward, technical support to overcome hurdles you may encounter will not be available. Just something to keep in mind.
  • 0 in reply to Ralph Jacobi
    Prodigy 130 points
    Thank you for such a timely and encouraging response!

    I have read the P2P documentation and I've spent quite a few hours running around the different layers of code in the reference design. I certainly appreciate the effort has been put into it! In an ideal world I'd port and implement the full stack and modify it to deal with my particular communication situation - but the learning curve for that state machine and the standards is very daunting and as ever in commercial projects, time to a working solution is short :(

    Missing packets isn't a big deal for me - it's a stateless comms protocol that is tolerant of missed packets, there would be time outs at the higher levels indicating a general loss of viable communications, but if I can get the basics working it would be nice to put in a bit of (proprietry) handshaking to acknowledge transmissions.

    I will push ahead and start trying to get some transmissions going between my boards.

    If I get a bit of time later on I could possibly make the basic code framework available for anyone else who'd like to use the TRFs in such a simplified manner.

    A couple of specific TRF questions, if I may?

    The Target Protocol Register:
    - Does it rely on a correctly formatted command byte from the initiator for all of it's bits? Or is it just the Pas106/Pas1443B that relies on a particular encoding for that command? (the others appear to be determinable from the modulation/encoding of the SOF etc. rather than the payload)
    - The cases handled by it (as listed on page 50, section 6.12.1) don't really clarify what happens if a valid command sequence is not received, I assume it just plows on in any case, making the received data available in the FIFO?

    Thank you again for your help!

    Cheers,
    Kyle
  • 0 in reply to Kyle Blay
    TI__Guru*** 128265 points
    Hello Kyle,

    The Target/Protocol Detection feature is used for keeping the TRF7970A in a low power mode, waking on RF field received, and then upon waking diagnosing what protocol is being used to communicate with it. This allows the device's ISO control registers to be configured and the command to be processed by the host MCU based on the standard identified.

    The detection is made by the modulation scheme and bitrate of data received.

    It doesn't care if the packet is valid, whatever data is given will go to the FIFO.