TRF7970A: NDEF standard vs short record support

Hello Robert,

I don't think I understand what you mean by 'NDEF Standard Records'. Can you clarify?

A Short Record is one of two Text Record formats defined, the other being a Long Record. Then beyond Text Records, there are others such as URI, V-Card, MIME, etc. - but among those I don't recall anything being defined as a 'Standard Record'.

To use your terminology, I meant long record.

Hello Robert,

The NDEF State Machine already supports reading Long Records. Any limits seen in the firmware are from that the GUI won’t display that information and the write functionality is limited. But the data is sent over USB and stored in a .hex file on the PC when connected with the TI NFC Tool GUI v1.8.

Hi Ralph,

Could you please elaborate on how NDEF long records are supported.

1) From what I can see, an buffer of 256 bytes is allocted to send and receive NDEF files. What happens when an NDEF record from the tag is bigger than 256 bytes?

2) It looks like an NDEF record isn't checked for long or short record. It seems like it's up to the user (e.g. me) to parse any incoming NDEF record for a long or short record status. Is that correct?

Regards,
Robert

Hello Robert,

The 256 byte buffer is used to store the portion of the message read out. That portion should be saved elsewhere or sent over USB/UART etc. to something that can store/process it.

The NFC state machine as a whole based on our configuration only supports 256 bytes (uint8_t is used for size parameters throughout) max packet size per transmission. So to read out more data than 256 bytes, you can do this but not in a singular NFC read command. Rather, for example, to read out a 2500 byte message, 10 commands reading out 250 bytes each could be used. After each command, the data should be stored outside of the buffers used for NFC, but by the end you will have all 2500 bytes.

For question 2), that is correct, the NFC stack doesn't care if it's a Long or Short record. That's an application/user specific topic. For our demo with the GUI the examples are really for short records too - though a long record can be read and sent to the GUI, and that gets stored in a .hex file.

Hi Ralph,

Suppose I know that the largest NDEF record I will get is, say, 1k. If we were to change the size of the buffer from 256 to 1024, would this be sufficient to have the NFC stack handle this message completely where we wouldn't have to add other code to buffer the message even more??

Regards,
Robert.

Hello Robert,

Are you talking about on the application side (T4T State Machine) where you want to do 4-5 read commands and store the data in a single buffer on the MCU side? Or are you wanting to read out 1024 bytes with a single read command?

I want to receive an NDEF record from the tag that is 1024 bytes.

Hello Robert,

I am out of office currently, and I will need to investigate the NDEF specifications before I give you full reply as to what is or isn't possible on that front and what changes would need to be made.

That said, I can say you would be making very complicated and significant changes to the TRF79xxA driver as you would need to change the entire driver from an 8 byte length of data message to 16 byte length of data message. That is not a trivial change and likely will take a lot of development time.

In all our testing of NDEF applications, all the vendors we tested with had max message sizes of 255 per read, thus is why we did the same. Whether the spec allows for more and how much more, I need to investigate when I am back later this week, but even if it is possible on a specification level, we did not design the driver to handle that based on what the common trend in the industry is and therefore it would be a large undertaking to make that change.