• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 16 subscribers
  • Views 1616 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP-EXP430F5529 + TRF7970ATB + NFCLink 1.0.0.3 + Stollman NFCPlayer 1.0.153.5

Marius Damian
Prodigy 30 points
Other Parts Discussed in Thread: TRF7970A

Hello,

we bought the MSP-EPX430F5529 and TRF7970ATB to test the NFC functionality and we seem to have a problem.

All steps in the document slou386.pdf were strictly followed, the correct firmware was loaded and the connection

between NFCPlayer and board works. We can start the different modes (the correct LEDs are blinking)

but the device seems to not react to the ISO 15693 cards or to the NFC cards that we try to read, when running in RW mode.

Also the Card Emulation mode does nothing when we try to read the data using an Android App (which is able to read the correctly formatted NFC cards).

 

The documentation specifies the NFCLink version 1.0.0.1 and we could not download that version.

Can it be that there is a problem in the newest version and that is why it’s not working?

Is it possible to download the older version 1.0.0.1 to test with or does anybody have an ideea what might be wrong?

We have 2 boards and both behave the same way, so a hardware defekt is excluded (I quess).

 

Thank you in advance!

Marius

  • 0
    TI__Guru*** 135355 points
    Hello Marius,

    Please see this guide which has been done for Version 1.0.0.3: www.ti.com/.../slou386b.pdf

    Also make sure there is a jumper between P2.0 and P4.0 as shown in Section 6 Hardware Configuration.

    I'm also curious what is your use case for this... the Stollman NFCLink solution uses NCI and is geared towards host-based systems where you need NCI to communicate with the OS.

    Most applications would find it better to use the TI developed NFCLink Standalone solution instead which supports NFC Reader/Writer, Peer-to-Peer, and Card Emulation and it includes full source code. This gives you far more flexibility, and unless you require NCI, it's the better way to go.

    You can evaluate that solution with the hardware you have as well. We don't have a User's Guide for Experimenter's board but the guide for the LaunchPad should give you most of what you need to know: www.ti.com/.../slou452.pdf

    You will need to have the jumper between P2.0 and P4.0 as well for this. If you have any questions about the setup for NFCLink Standalone with your hardware, feel free to ask me here and I can fill in details.
  • 0 in reply to Ralph Jacobi
    Prodigy 30 points

    Hello Ralph!

    Thank you for your quick reply. This was indeed the problem. We somehow missed that jumper in the description (it is also displayed in the slou386.pdf)...

    Is the TI NFCLink solution the one that can be downloaded here www.ti.com/.../sloa208? Then we used both NFCLink solutions and both did not work, but now they do :).

    We actually tested right now with the TI solution and it works great.

    To answer your other questions:

    We are using the TRF7970A in one of our devices and we need to communicate with a handheld that supports only the Reader/Writer Mode and we have no way of controlling the communication at a lower level (it is a Honeywell Dolphin CT50 with Windows 10 IoT Mobile Enterprise). Therefore,  our device must act as an NFC card and the handheld as NFC reader and the data will be transferred from/to device in one Read/Write session.

    We also intend later to implement the Reader/Writer Mode in the device and use different Android phones working in Host Card Emulation mode. This will give us more flexibility when trying to upload a new firmware to the device or other bigger data.

    This brings me to my next question: in the TI solution we noticed that the CE mode is limited to 246 bytes. Is this a limitation in the "TI NFC Tool" application? We need to transfer a lot more data between the handheld and our device and because of the handheld limitations we need to do this in one session (otherwise the user would have to remove the handheld from the device and bring it back in the NFC field to recognize the device again and continue with the transfer, but this is not user friendly). What would be the maximum that we can transfer in one Read/Write?

    Thanks again and regards

    Marius D.

  • 0 in reply to Marius Damian
    TI__Guru*** 135355 points
    Hello Marius,

    The CE mode limitation is only from the TI NFC Tool. The USB buffer between the PC GUI and F5529 is 256 bytes which is the only limiting factor. If you run the firmware in standalone mode (no GUI connected) you can toggle the S1 button to run through a few NDEF messages and the S2 button will display a ~3.5kB image! The buttons aren't the greatest on that board so it may take a few clicks to get it to register.

    I think using the TI NFCLink Standalone firmware would be the best fit for your application.

    Regarding Android and HCE, the amount of phones which support HCE are growing but there are a lot of older devices which do not. If you want to get the best interoperability with older devices you should also consider using Passive Peer to Peer mode.

    This would also let you get faster data rates more consistency as it is hard to say which Android phones will support the faster RW data rates above 106kbps with HCE. Peer to Peer is great for firmware upgrades like what you described, and you can use 212 kbps for pretty much any NFC enabled smartphone (I dislike blanket statements but I havent found a phone which doesn't do 212) and even 424 kbps for most. Keep in mind that's over the air data rates and overhead/processing slows that down plus the transfer speeds vary from device to device but in general you can expect about 6-12 kBytes/sec with most Android devices.

    Keep in mind you will want to use Passive Peer to Peer and not Active Peer to Peer. The naming may make Active sound more attractive but it actually has worse interoperability with Android handsets than Passive across all data rates and will have lower ranges and slower throughput as well. It's not meant to be used for a use case like yours.

    Our Peer to Peer app note can provide more technical details about the technology: www.ti.com/.../sloa192
  • 0 in reply to Ralph Jacobi
    Prodigy 30 points

    Hello Ralph,

    thank you for your valuable inputs.

    Using the Peer to Peer mode in Android would mean that the user has to use the Beam UI when trying to send the data to the device. AFAIK the Beam UI cannot be overriden and this is an extra step for the user we do not want to have (it was possible before Android 4 to do it without the Beam UI but after 4+ it is no longer possible). The HCE mode is supported in many Android phone and Apple has the Apple Pay which for now supports only the Card Emulation through Secure Element. I read somewhere that it may be possible that Apple implements the HCE mode also in the future, so we are hoping that by choosing HCE we will be able in future to also have the App on iPhones (let's see what the Apple future brings).

    Regards

    Marius D. 

  • 0 in reply to Marius Damian
    TI__Guru*** 135355 points
    Hi Marius,

    That sounds fair. If you configure the device right, you could actually cover all modes without major issues.

    One thing to keep in mind is that polling for tags vs polling for NFC devices can overlap at times.

    If you want to support both HCE (which uses Type 4A/4B) and Peer to Peer, one thing you could do is:

    Poll for Reader/Writer Type A and B
    Poll for P2P Type F (212kbps+)
    Target mode Card Emulation A and/or B. If you can get away with only doing CE Type B, then you could even be a P2P Target for A.

    What you want to avoid is overlapping: Poll Reader Type A+P2P Initiator Type A OR Target Card Emulation Type A+P2P Target Type A

    If those overlap, the results can get very mixed and unpredictable depending what is activated first by an NFC phone.

    The other trade off is just code size to support P2P as well.

    Anyways, that's an option to maximize your interoperability and give some future proofing by letting HCE be supported too.

    As for Beam UI, not sure how that works as far as disabling, but fair point if that's an issue, you could maybe have a further setup where P2P isn't enabled by default but sending a command or something would allow it to turn on to support older non-HCE devices.

    Just some ideas to consider as you evaluate for your application.