NTAG5 pass-through mode strange behaviour

[tedarcpicker]

Hi,

I'm developing with the NTAG5 link, is there an errata document for this chip?

Because I've been noticing some strange when communicating in pass-though mode, i.e. when continuosly and simultaneous polling the SRAM_DATA_READY and/or NFC_IF_locked session registers from the I2C and NFC perspectives, sometimes the chip seems to enter in a blocked state where not even access to the session registers is possible...

What may be causing this?

Thank you.

[komal18apr]

I am also developing a pass-through mode with NTAG5 link and experiencing no communication for SRAM transfer. Here, the same procedure is used as described in AN12364 document. Also want to know about the ED pin clear session register correct address, because I found different addresses in datasheet and the AN12364 document.

[Daniel_Gutierrez]

Hello @tedarcpicker, Good Day!

Thank you very much for your interest in our products.

I would like to ask if you could you please describe the process that you have been following? And if you could please provide more details on your setup, such as what are the software libraries used to communicate via NFC? I would also like to ask what is the specific error that you are getting and when does it happen? Is it related to the NTAG not responding to the NFC/I2C commands?

Please consider that for proper communication using pass-through mode, some bits on the session registers need to be handled via I2C. You may find a detailed description of the pass-through mode communication process in the NTAG 5 - Bidirectional data exchange Application Note, along with the registers that have to be written.

You may find the name of those bits and their effects in section 8.1.4 and section 8.1.3.13 of the NTAG 5 Data Sheet.

My best regards,
Daniel.

[tedarcpicker]

Hi!
I'm not using any libraries, just register programming using an STM32 microcontroller to fill the 256 bytes of the SRAM to be sent to the phone or an NFC reader wirelessly, however, it sometimes happens that a first read of the 256 bytes occurs as normal, but in the consequent reads after that I only receive "010F" error messages (being the sent command exactly the same), moreover not even the session registers are available, I have to manually power down the chip by unplugging the VCC wire to reset it...
Since it is being powered by the MCU the energy harvesting is off, but the presence of a big eletromagnetic field may be interfering with the NTAG5 chip? It shouldn't...

[Daniel_Gutierrez]

Hello @tedarcpicker, Good Day!

Please refer to section 6.2 of the NTAG 5 - Bidirectional data exchange Application Note in which you will find a detailed description of the specific process that has to be followed when using pass-through mode to transfer data from an I2C host to the NFC reader device.

Please consider that in this mode the NFC device cannot read the SRAM constantly all the time since, it has to wait for the SRAM_DATA_READY (from the status register) bit to be set to 1 before sending the SRAM_READ command.

Consider as well that a specific configuration for this mode has to be set by the I2C host by writing to the session CONFIG_x_REG and ED_CONFIG_REG. For further details please refer to section 8.1.4 of the NTAG 5 link - NFC Forum-compliant I2C bridge.

After configuring these registers as described in the application note, the I2C host will write the SRAM blocks, and then wait for a LOW state on the ED pin, condition that will be met when the last byte of SRAM data has been read via NFC then, the host can access SRAM again.

An important aspect to highlight is that the ED pin is an active LOW signal. So due to open-drain implementation, you may consider adding an external pull-up resistor on this pin to ensure its logical state when inactive.

Additionally, I would like to ask if you are using a development kit for the NTAG 5 link such as the OM2NTP5332 Or is it a custom board?

My best regards,
Daniel.

[tedarcpicker]

Hi!
Thank you. It seems that some cause of my problem was that when an I2C communication error happened between the MCU and the NTAG5, the i2c bus was not correctly closed and some forcing was needed.

Nonetheless, another question that I have is regarding the maximum data rate that can be achieved with this pass-through mode... if the MCU writes the 256 bytes at 300Hz, is there any time limitation on the NTAG5 to be able to initiate communication with the reader?

[Daniel_Gutierrez]

Hello @tedarcpicker, Good Day!

Data rate in pass-through mode depends fully on the individually set data rates for each NTAG interface (I2C or NFC). Consider that the NTAG 5 I2C slave interface supports both standard (up to 100 kHz) and fast mode (up to 400 kHz) communication speeds for both read and write. Bitrates supported for NFC communication are described in Tables 112 and 113 of the NTAG 5 link Data Sheet.

Please consider that in pass-through mode, only one interface is active at a time for preventing timing issues, since they should be waiting for the SRAM to be accessible by checking SRAM_DATA_READY, PT_TRANSFER_DIR and the ED pin respectively. Please ensure the flow described in NTAG 5 - Bidirectional data exchange Application Note is being met at implementation.

My best regards,
Daniel.

[tedarcpicker]

Hi!
Thank you. On table 113 it is displayed a data rate of 53kbps if a "single subcarrier" is used, this should be slected on the reader or can be defined by a register of the tag?

[Daniel_Gutierrez]

Hello @tedarcpicker, Good Day!

Subcarrier mode is selected by the NFC reader using the first bit of the field "flags" in the protocol header. For further details please refer to section 7 of the International Standard ''ISO/IEC 15693-3''.

My best regards,
Daniel.

[tedarcpicker]

Hi!
Thank you. I've been trying to read to read the 256 Bytes with delays of 1 to 10ms between reads... however, although the MCU has already written to the tag SRAM, the NTAG5 responds "010F" if the delay between reads 1ms and I only can read the full SRAM data when around 10ms have passed... is it normal? what is the maximum read rate for the tag SRAM via the air interface?

[Daniel_Gutierrez]

Hello @tedarcpicker, Good Day!

Please consider that NTAG5 pass-through mode is meant to be implemented for an efficient communication between an I2C host and an NFC reader device, enabling this mode would eliminate the need for any delays, since the flow is based on the polling of the flags SRAM_DATA_READY and PT_TRANSFER_DIR, so any additional delays could cause pass-through mode to not work as expected.

I would like to ask if you could please confirm that the SRAM is trying to be read by the NFC device, or are you trying to read the SRAM with the same I2C device with which it was written?

Please take into account that a reading from NFC device can only happen when SRAM_DATA_READY = 1, and this flag will be set to 1 after the I2C device is finished writing. Once the memory has been read by the NFC device, the flag will be set to 0 and it won't equal 1 again unless the SRAM is written again by the I2C host.

My best regards,
Daniel.

[tedarcpicker]

Hi! Thank you. Yes, the reader is trying to read the NTAG5 SRAM continuosly at each 1ms or 10ms via the NFC interface, independent of the it being already ready or not. Since I'm writing with the MCU at more than 300Hz and there's the arbirter opening it only to the I2C after the read, with my tests it seems that the data rate achieved is bigger (i.e. amount of batches of 256bytes read). The NTAG5 seems to respond faster if I don't do the polling on the SRAM_DATA_READY = 1, and continuosly "knock" on the SRAM to try to read...

However, I've noted some reads of errors "010F" on the reader, while the MCU is telling me that it has already wrote the 256Bytes, so the data should have been ready to read (with SRAM_DATA_READY = 0)...

[Daniel_Gutierrez]

Hello @tedarcpicker, Good Day!

Please note that the I2C bus standard mode can transfer data at a rate of up to 100 kHz in standard mode and 400 kHz in fast mode, this does not imply that communication will not work with lower frequencies, however if the goal is to increment data rate for efficient communication, you may consider increasing the I2C bus frequency to a rate closer to the ones supported. 

I would like to ask how many successful readings of the SRAM via NFC are taking place? Is it just the first one that is successful and all readings after that return "010F"?

I would also like to ask, after the NFC device reads the memory is the MCU writing to the SRAM again? Or does the MCU only write the memory once?

My best regards,
Daniel.

[tedarcpicker]

Hi,
Thank you. The first reading if the SRAM via NFC happens correctly, then it is asked again after 1ms and it returns "010F", then asked again 1ms later and returns "010F" again... then after the 3rd or 4th ask it reads the SRAM correctly again, and the cycle repeats...

Regarding the second question: yes, after the memory is read via NFC, the MCU checks in the session register that it was and writes more data. While the NFC reader is giving "010F" errors I can see that the MCU is stating that it already wrote the data on the NTAG5.

[Daniel_Gutierrez]

Hello @tedarcpicker, Good Day!

For a proper implementation of the pass-through mode please ensure the following configuration of the session registers is being handled correctly by the MCU before writing to the SRAM for the first time:

Consider that the ED pin has to be used in this mode since a logic LOW state on this pin will let the MCU know that it can write again to the SRAM. Additionally, note that any delays will interfere with the flow of the pass-through mode, I would strongly recommend to constantly read the configuration registers from the NFC side with the READ_CONFIG_REG command (A0h) to check SRAM_DATA_READY == 1.

Please consider that a 300Hz frequency on the I2C side would lead to a relatively slow communication speed.

To increase the data rate in this mode, please increase the I2C frequency to around 100kHz for standard mode.

My best regards,
Daniel.