ST25R3916 Card Emulation Mode Initialization

[bentech]

Hi all,

  I have designed and built a custom circuit using the ST25R3916 (in differential mode with AAT) and a ATxmega128A4U micro controller. I have spent the last two weeks trying to get it working so my phone can detect it as a card as a starting point. Eventually I want to the phone to read data files from the device.

  I believe I have the hardware working, as I have a 13.56MHz signal on the antenna which is +-7V and I get EON and EOF interrupts when I place my phone over the antenna.

  However, I am not able to get the phone to detect it as a card. I feel that I am 90% of the way there, but I am struggling to understand the configuration of the chip fully and the RFAL code in ST25 embedded lib (STSW-ST25R016 for 3916) which I have spent quite a bit of time looking at. It is way more complicated than I need and I cant find the basic initialisation that I need.

  I have been through other forum threads including this one, and tried to replicate the register settings without luck.

  Could anyone help me with a step-by-step initialisation for CE mode (ISO14443A) including the registers and values I should be setting, and a bit of a description on what needs to be managed in the interrupts?  I feel that with this, I will gain a better understanding of the process and can then continue to develop the project.

  Eventually I believe I will need to use ISO-DEP (ISO/IEC 7816-4) protocol for data transfer, but that is for another day.

  Any help would be greatly appreciated. Oh, and if there is anyone in little old New Zealand that has experience with these chips, I would love to catch up for some advice. I am happy to pay for a consult.

[Ulysses HERNIOSUS]

Hi bentech,

quite some work if you want to implement all this on your own. A very simple flow would look like this:

Initially put the 3916 into correct bitrate detection mode with automatic answers enabled and interrupts enabled. After receiving I_eon, the MCU needs to confirm operation within 10ms. Then the device will handle Anticollision/SDD autonomously. Next frames which may need to handled are RATS  and potentially HLTA. 

For actually getting recognized by a phone more actions are likely required: Proper handling of HLTA, proper handling of RATS and likely even proper handling of ISO-DEP protocol (R(ACK)/R(NAK handling for presence check). Full ISO-DEP is then required to present an NDEF to the smartphone.

If you really want to implement this on your own, I would advice to start with a simple NFC reader where you can send frames one by one and observe how you respond to it. Then in a next step observe (SPI/code logs) how one specific phone reads the existing demos from ST25 NFC lib.

For being interoperable with multiple phones you will need  quite some code and understanding of the protocols...

BR, Ulysses

[bentech]

Ulysses,

  Thank you for the reply. I have been going through the ST25 embedded NFC library (for STSW-ST25R016) and I was under the impression that does what you describe right? If so, I just need to model my implementation off that. Am I correct in that the rfalRunListenModeWorker method is handling the processing of the communication stages?

If my end goal is to be able to transfer a file, say 100K in size, to a mobile application (when the user taps on a device), what would your recommendation be in terms of the NFC mode to use and the implementation? Is the ST25R3916 even the correct chip to be using?

I don't have a NUCLEO board, but I don't need to support multiple phones at this stage, just to get the basics working to evaluate how it works (on a single Samsung Galaxy mobile) and how long a transfer would take.

[Ulysses HERNIOSUS]

Hi bentech,

yes, the ST25 embedded NFC lib with its pairing demo does what I described. Correct for the rfalRunListenModeWorker() but I think there is also another demoworker for handling the app part - providing data to either t3t or t4t card emulation.

what is your requirement on data throughput of these 100K?

E.g in https://community.st.com/t5/st25-nfc-rfid-tags-and-readers/the-write-speed-is-too-slow-when-writing-date-into-half-duplex/m-p/646269 there was some discussion about achievable throughput.

BR, Ulysses

[bentech]

Hi Ulysses,

  What other demoworker should I be looking at to implement card emulation? At this point I am not too worried about the card type, just to get by board detected by my phone as a card and read some data from it. That would be a good start.

  To transfer the 100K the user has to hold their phone over the device, so I think 10s is getting too long. You indicated in that thread that you could achieve 30KByte/sec, which would be good enough I think. What NFC mode would I use to achieve this? Would it be CE mode? How would I go about setting up the ST25R3916 to be detected by a phone and transfer data in this way?

[Ulysses HERNIOSUS]

Hi bentech,

I was referring the demoCycle() -> ... -> demoT3T()/demoT4T(): These are responsible for emulating a memory and answering the various Read commands from NFC side.

The 30K/s was achievable data, basically between two 3916 in NFC-F/T3T at nominal 424kbps. I expect a phone to be slower - you will need to do some experiments but I could imagine that on some models you will end up in the 10K/s range.

Best Regards, Ulysses

[bentech · Accepted solution]

Ulysses,

  It looks like demoCycle is polled to start with and when the user presses the button it goes into demoCE for NFCA card emulation. Is this correct?

  Then, in demoCE it progresses through activated, dataexchange, discovery and sleep states and calls the demoCeT4T function for handling the data exchanges. Is this the function you mentioned in your last post (in the file '\Projects\STM32L476RG-Nucleo\Applications\Common\Src\demo_ce.c').

  From there, it calls the demoCeT4TSelect, demoCeT4TRead and demoCeT4TUpdate functions for getting the response data.

  If all that is correct I think I can follow that and model it in my code. That would help me understand the process better.

  If I am wrong, please correct me with the files and line numbers.

[Ulysses HERNIOSUS]

Hi,

I think your conclusions are correct.

Not sure about the part about the user button - where do you think the pairing demo changes its behavior depending on it being pressed?

Regards, Ulysses