How many characters can an NDEF2 record hold?

[stevewald]

I am using the NHS3100 to develop a smart card application and running into an NDEF2 record limit of about 460 characters. Why is it so few? Is there a work-around? Can I create an extension for the original NDEF2 record?

[Kan_Li]

Hi Steve,

The driver of NHS3100 SDK supports long record, so it depends on whether the application uses long record or short record, but as NHS3100 just has 8K SRAM, so short record is recommended.

Hope that makes sense,

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[driesmoors]

To amend:

The ARM in the NHS3100 has access to 128 pages of the NFC memory. The maximum size of an NFC message can therefor not be bigger than that. This poses limitations to the maximum payload that can be carried by one NDEF record. The length of the mime string and the existence of possible extra non-NDEF messages add extra constraints on the maximum size of the payload.

Note that the 8Kb SRAM in the NHS31xx is accessible _only_ by the ARM. It doesn't sound like much, but it is plenty for all the work the ARM needs to do, be it validation, budget calculation, compression or encryption.

Best,
Dries.

[stevewald]

Hello, Kan Li and Dries,

Please let me rephrase the question: How can I transmit up to say 1024 characters in NDEF2 record(s) over NFC for inclusion in a cellphone contact-card list?

We are producing smart business cards with the NHS3100 and finding an effective limit of about 460 characters. TagInfo claims a max message size of 518 bytes, but won’t read the record when larger than the 460 limit. We’d be happy to split the record given a method for doing that. We have had several clients submit cards with longish titles, addresses, websites, several phone #’s, etc. 460 is just not enough bytes for the general case. I just don’t see how to do it, and it seems wrong to have to snip and cut away at a customer’s data request.

Now that I have your attention on this subject, I’ll bring up all the issues we are up against for smart business cards…

1. The short NDEF2 record size limit for NFC tag reads mentioned above.

2. We need to understand how to run LPCXpresso in batch mode in an effort to automate the process of producing & programming the business cards.

3. We would especially like to be able to program many tags with one generic business-card tag firmware, leaving the card data for each specific client to be later transferred to NoVRam without reprogramming. Perhaps this could be done using TagWriter to edit and store the data. This would need to be script-automated at our end, with the ability to give simple instructions to the client to modify his own smart-card data at his/her convenience.

Steve

[Kan_Li]

Hi Steve,

Please refer to the following for details.

1.       The short NDEF2 record size limit for NFC tag reads mentioned above.

- According to the spec, the payload length in a short record is between 0 to 255 octets.

2.       We need to understand how to run LPCXpresso in batch mode in an effort to automate the process of producing & programming the business cards.

 -Do you mean download the firmware? if yes, it is more related with the debug probe side, and when you use LPC-Link 2, with tool LPCScrypt , you may download image with script. Please refer to 4.1 Basic LPCScrypt usage in https://www.nxp.com/docs/en/user-guide/LPCScrypt_User_Guide.pdf for details. You may download it from https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/...

3.       We would especially like to be able to program many tags with one generic business-card tag firmware, leaving the card data for each specific client to be later transferred to NoVRam without reprogramming. Perhaps this could be done using TagWriter to edit and store the data. This would need to be script-automated at our end, with the ability to give simple instructions to the client to modify his own smart-card data at his/her convenience.

- Yes, TagWriter can do that, as well as a NFC reader like PN7462 or something like that, the NFC reader library provides NfcrdlibEx9_NTagI2C for this reader, which run POLL mode of discovery loop, and detect the NTag I2C    cards and displays detected tag information like UID, ATQA, SAK, Version   info, Page Read and Page Write status. You may use it as a starting point.

Hope that helps,

Best Regards,

Kan

[stevewald]

Thanks, Kan.

I can see a couple of items that I wasn’t describing clear enough.

1. I am already setting to FALSE the ‘shortRecord’ byte of NDEFT@T_CREATE_RECORD_INFO_T which is given to NDEFT2T_CreateMessage(), but if the *pString payload length exceeds 462 bytes, even TagInfo won’t read it. What else do I need to do to increase this length limit?????

2. Actually, I want to run the build/make to compile the project, then load the FW to a chip. I am looking into LPCScrypt now to see if it will do that. Thanks for the links.

3. What does this PN7462 do that an Android smart phone reader and TagWriter will not, given the right script for production? Why exactly do we need a Polling discovery loop and tag status etc.? Please justify the expense.

Steve

[driesmoors]

There may be some confusion about 'programming' - at least with me.

• There is 'programming the firmware in the Flash memory of the NHS3100.
  This can be done in several ways, which are described in SDK 11.1 > docs/AN_NHS31xx_Flashing.pdf. Keep in mind that flashing will require an external power supply, as the energy harvested by the field alone is not sufficient to sustain such an operation.
• And there is 'programming the NFC contents'.
  The ARM has only access to 128 pages. This portion of the NFC memory is not persistent and can - and must - be filled in by the ARM at startup (when the phones taps the tag). It is not possible for the ARM to create a message bigger that that.

[stevewald]

Not possible to create a message bigger than 512 bytes? Why don't we compress it then?

[driesmoors]

That may be feasible - you can create your own firmware to do just that - as long as you keep in mind which applications you want to be compatible with.

KR,
Dries.

[vrushali_b]

Hi

I want to write and read 2kB data to EEPROM of NHS3100 through NFC. but Due to restriction of NFC_Shared memory of only 512 bytes, How can do it? 

[stevewald]

Vrushali,

The right answer was never given in that thread but in this thread which popped up several months later:

https://community.nxp.com/message/1020255

Please make a note of it.

Steve

[Kan_Li · Accepted solution]

Hi Steve,

As Dries said, the hardware limits the maximum payload that can be carried by one NDEF record, and there are other extra constraints on the maximum size of the payload. so you can not set the length too long even within the spec. and if you look into NDEFT2T_CreateMessage() , you may find it doesn't check the length , but  the CreateRecord() will return false in the following cases:

-# Size of the NDEF message being created exceeds the size of message buffer allocated by caller

 -# Size of the NDEF message being created exceeds the size of the shared memory

Please kindly check if that is the cause of your issue.

The firmware running on PN7462 does the same as an Android smart phone reader running TagWriter , it is just an alternative choice for you, and you may add your own code to program the tags in each Polling discovery loop.

Best Regards,

Kan

[stevewald]

Dries,

What about using multiple record chunks in a single NDEF2 message? Could we program the ARM to divide the message into N chunks of say 400 characters, and shift the chunks into the 128 page accessible buffer as needed? If not, what good is the 7.5kB of SRAM that ARM has no access to??? I don’t understand this restriction at all.

Steve

[stevewald]

Kan and Dries,

Ok, I’m finally getting an answer with a number in it for the non-short NDEF2 record. As Kan pointed out, the size of the message cannot exceed the buffer allocated by the caller. The caller in this case is NDEFT2T_CreateMessage(), for which the buffer is a byte array of NFC_SHARED_MEM_BYTE_SIZE, which is defined as the size of an NSS_NFC_T. This NFC type contains a memory buffer of 128 4-byte words (512 bytes). So after accounting for whatever Mime and NDEF2 message overhead (my assumption) it’s down to 462 bytes. This is an abysmally small number for what I thought should be many times the size of a short record. I don’t suppose that there is a way to safely increase that size without breaking something in the chip_nss library?

As Dries understood, this smart business card does not use the temperature sensor, but simply stores a gob of user information to regurgitate upon the reader when tapped. I tried splitting the information into two NDEF2 records of roughly equal size, but either the first record was over-written, or the reader lost it when the second came was received.

As for my #2 and your confusion about programming – I want to program ONE firmware for all business cards, and program DATA for every card. I don’t care which memory either resides in, but the card (tag) needs to work as a passive element without any batteries, and without needing complex command/response scenarios from the reader. TagWriter should be able to dump new DATA into the card, even if it means leaving the card tapped for 10 minutes. Failing this, our fall back is to program unique firmware for every single card.

More questions for Dries…

1. “The ARM in the NHS3100 has access to 128 pages of the NFC memory” What is a page in this context? A four-byte word again? I am still only asking for 1024 bytes!

2. “You write simple firmware that stores multiple NDEF messages, and cycles through them on each tap.” Right. How? I can create the multiple NDEF messages without problems. I don’t see where even the first message gets sent out for the tap. Can you send or point to an example for multiple messages?

Steve

[driesmoors]

Hi Steve,

I have been thinking about the use case you described. I don't see how the NHS31xx fits into this: there are much cheaper ICs that can do what you want without the disadvantages that come with the NHS3100 IC (they also don't have the advantages, but you are not considering those for this use, so no loss for you).

The best way forward seems to contact a local sales contact - Regional and Sales Contacts|NXP  - so they can help you with getting access to the correct ICs you want in the shape you want them.

Best,
Dries.