8 bytes Capability Container (CC) instead of 4 when adding NDEF record to ST NFC tags?

[chai2145]

 

Hello,

I’m working with an ST NFC tag (e.g., ST25DV) and noticed that when I add an NDEF record using the ST25 mobile apps, the system automatically adds a 4-byte Capability Container (CC) to the NDEF message record.

My question is:
Is there a way to append or extend the CC to 8 bytes instead of the default 4 bytes when adding an NDEF record?

 

 

[France Berthelot]

Hello

DV is a type5 Tag

Type 5 tags are based on the ISO/IEC 15693 standard (also called NFC-V or Vicinity)

The CC file is a mandatory data structure in NFC Forum-compliant tags.
It describes the tag’s memory layout, access conditions, and supported features

 

The CC file is typically 4 bytes (can be longer for extended features)

The CC (Capability Container) file on NFC Forum Type 5 tags is typically 4 bytes, but it can be longer in certain cases, especially when the tag supports advanced features or extended memory.

• Extended Memory Support (More Than 2040 Bytes)
• If the tag has more than 2040 bytes (e.g., 4 KB, 8 KB, or more), the CC file must be 8 bytes to encode the larger memory size and additional features

How Is the Length Determined?

• If the tag’s memory is ≤ 2040 bytes:
  The CC file is 4 bytes.
• If the tag’s memory is > 2040 bytes:
  The CC file is 8 bytes (or more, if required by features).

I do not know on which Tag Memory size you work on, but check memory size, this will explain CC file size.

CC file do not extend to be 4 or 8 bytes long, according to NDEF records stored dynamically!

You define first in CC file the size allowed to the NDEF part, after that according to previous, you can write up to max size with records.

The application rewrites the CC file, if memory doesn’t contain one, according to Tag memory size.

 

To answer to the Question : No.

 

To define a CC file, yes, you can use the Memory content menu, and write manually bytes. Not recommended!

Hoppe this clarify.

Cheers,FB

[chai2145]

I’m using the ST25DV04KC-J. When an NDEF record is added using the ST25 app, it automatically appends 4 bytes of CC. However, my system (MCU) expects a CC length of 8 bytes and always reads the NDEF record with an offset of 8 bytes. This mismatch causes the NDEF record to be read incorrectly.

[JL. Lebon]

Hello, 

Why is your system expecting a 8 Bytes CC File?

There is no reason for a system to expect a fixed number of bytes as the CC File in Type 5 can be either 4 or 8 Bytes. The system should relay on the first bytes of the CC File (Magic number E1 or E2) to determine if the CC File is coded on 8 or on 4 Bytes.
I think it would be better, if you have the possibility to modify it, to adapt the MCU firmware to check the size of the CC File instead of relying on a fixed size of 8 Bytes.

Best regards.

[chai2145]

Because it uses ST25DV64KC 

[JL. Lebon]

Sorry but I'm lost. 
You said that you are using a ST25DV04K.
So is it a ST25DV04K or is it a ST25DV64K ?

Best regards.

[chai2145]

Sorry previously using ST25DV64K , but no stock and change to ST25DV04K for new PCB 

[JL. Lebon]

Ok.
I pretty sure that the ST25app is automatically creating a 4 Bytes CC File in case the tag is a ST25DV04K and an 8 Bytes CC File when the tag is a ST25DV16 or 64K. I don't think you can change this behavior.
You can still try to write your own 8 Bytes CC File in a ST25DV04K using the manual Write memory inside the ST25 app if this is really what you want. You can have a look at the application note AN4911 (https://www.st.com/resource/en/application_note/an4911-ndef-management-with-st25dvi2c-series-and-st25tv16k-and-st25tv64k-products-stmicroelectronics.pdf) to understand what to put inside the CC File.

Nevertheless, I strongly recommend to rather modify your MCU firmware to support both 4 and 8 bytes CC File. This is much more future proof.
The MCU must first read the first 4 Bytes. Then it can determine if the CC File is 4 Bytes or 8 Bytes by checking the Byte address 2 of the memory (3rd byte of the CC File). If it is equal to 0, then the CC File is on 8 Bytes, if it is >0 then it is the MLEN value and the CC File is on 4 bytes. Additionally, the first Byte of the CC File (Byte 0 Magic number) can be checked: E1 usually means 4 Bytes CC File and E2 usually means 8 Bytes CC File. Nevertheless, the NFC Forum specification says that 4 Bytes CC File can exists with E2. This is why MLEN is the right byte to check, even if no one is using the E2/4 bytes arrangement (and I don't recommend using it for compatibility reasons). Practically, checking that the first byte is E2 is usually enough.

Best regards.