x-nucleo-nfc08a1, card emulator mode

[mgelosa]

I'm using X-NULCEO-NFC08A1 with NUCLEO-L476RG and sw sdk X-CUBE-NFC6 (project X-CUBE-NFC6\Projects\NUCLEO-L476RG\Applications\NFC08A1_PollingTagDetect).

I'm using an IPHONEX (ios16.5) with a custom app that writes nfc tag (but I've also tried the freeware version of app NFCTool available on the store).

The ST25R3916B should act as CARD EMULATOR and READER (both modes...but I've problems in CARD EMUL. mode)

Everything well, till when the data size written is lower than 90-100bytes...BUT when I try to write (from IPHONE to X-NUCLEO) a tag with bigger data size (for example 150bytes), it happens that last bytes (for example the bytes from 130 to 150) are written over the first bytes of the buffer.

I've spent many days to reselve this issue without succes.  any hints ?  

may I have the sw project NFC08A1_PollingTagDetect already configured to perform this task ?

thanks

[Ulysses HERNIOSUS]

Hi mgelosa,

not completely clear what you are doing... PollingTagDetect to my knowledge does only act as Poller not in card emulation.

Writing a tag typically means using commands to write into EEPROM of the tag. ST25R3916(B) can emulate such (we are providing a demo as part of ST25 embedded lib). Typical command sets are specified by NFCForum as T2T or T4T.

So: Which commands/APIs are you executing from iPhone side. How do you receive on ST25R3916 side? Where do you see bytes being overwritten? Directly inside FIFO? Inside memory of the STM32L4? After which functional calls?

Best Regards, Ulysses

[mgelosa]

Hi Ulysses, 

thanks for your reply.

“\X-CUBE-NFC6\Projects\NUCLEO-L476RG\Applications\NFC08A1_PollingTagDetect\STM32CubeIDE"  project for ST25R3916B works both as nfc reader and/or card emulator 

I try to write from IOS phone a NFCA type T4T text message to x-nucleo-nfc08a1 + nucleo-l476rg.

The writing process is successfull if apdu is around hundred byte. The writing process is UNsuccessfull (bytes overwritten) if apdu is longer (for example with 150bytes). I debug global buffer "gNfcDev" at the end of dataexchange process. I included a document to explain better the situation.

thanks

[Ulysses HERNIOSUS · Accepted solution]

Hi mgelosa,

I think there is a misunderstanding: The implementation shown emulates a T4T tag (demoCeT4T()) demo. Its emulated memory will be written by potentially multiple frames/write commands being exchanged. The actual written data will end up in an array ndefFile within demo_ce.c. 

I suspect that your message is written as two frames and you look at a buffer having the last data in the beginning and some older left-over date (beyond the length) at the end.

Please check, Ulysses

[Brian TIDAL]

Hi,
NFC Forum T4T specs [T4T] define Maximum R-APDU data size (MLe) and Maximum C-APDU data size (MLc) as part of the CC file. According to [T4T] requirement 5.4.1.3 The Reader/Writer SHALL set the number of data bytes, to be written with a single UPDATE_BINARY Command, smaller than or equal to MLc.
MLe and MLc in the Card Emulation demo are currently set to 7Fh (127) in the CC file and size of some buffers is set in accordance.
Therefore, it is not allowed to send a C-APDU with a payload size bigger than 127.
Writing of more than 127 bytes have to be split in several UPDATE BINARY command with relevant offset parameter.

Rgds

BT

[mgelosa]

Hi,

Ulysses -> you're right. The correct buffer is ndefFile! and I can see the entire message without errors! thanks!

Brian -> thank you for your reply. I see the MLc and MLe definition you are talking about; they are 0x7f. The buffer ndefFile[NDEF_SIZE] has a size of 2048bytes. We are actually transmitting 190 bytes from IOS and everything is OK! I guess that ST's NFC libraries and IOS manages data packet accordingly....We are using the following plugin into IOS system (https://github.com/franckbour/Plugin.NFC) in order to write NFC packet.

We are trying to investigate further if everything is correct as it seems!

We are going to replace, for improvement purposes, many ""thousands"" of electronic boards mounting st25r3911 and already installed on the field with this new boards we are actually developing mounting st25r3916b. I need to be very sure that everything is correct and behaviour always repeatable and deterministic. Therefore every further hints from you is well accepted. Thanks !!!