cancel
Showing results for 
Search instead for 
Did you mean: 

RF Writing is not working on ST25DV64

HABIJ.1
Associate III

Hi,

I am working with a ST25DV64. I succeeded reading and writing via I2C. I can also read via RF interface. But I have not succeeded writing via RF interface.

I checked the static registers and there is no write protection,  I have one area and RFA1SS = 0.

Do I miss something? Thanks for your help

1 ACCEPTED SOLUTION

Accepted Solutions

Hi,

what you show in red is:

  • the Capability Container (CC) in block #0. The CC manages the information of an NFC Forum formatted Type 5 Tag
  • A part of the NDEF_Msg_TLV starting at block #1 with T = 03h, L = 2Bh and V being the content of the NDEF with a Bluetooth pairing record.

What you show in green is the last part of the Bluetooth pairing record (with the device address if i am not wrong).

The NDEF format is specified in the NFC Forum NDEF Technical Specification. 

In the factory all blocks of user memory are initialized to 00h (see ST25DV Datasheet). If NDEF is being used in your application, the CC and an empty NDEF have to be configured into the tag. See AN4911 (NDEF management with ST25DV-I2C Series) for detailed information.

It is likely that the tag is not NDEF formatted and that your application just writes the BT device address in the memory. Make sure to format the tag and make sure your application properly writes NDEF records. You can use the ST25NFCTap app on Android to check that the tag is properly formatted (see CC menu and NDEF menu).

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

9 REPLIES 9
Brian TIDAL
ST Employee

Hi,

can you show which command is being sent to write?

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Thanks for the reply.

Well, to give all the context : I suspect RF write problem in a bluetooth NFC pairing I am trying to implement.

For that,  I have a standalone ST25DV64 IC connected on a custom board with a bluetooth module. I would like to do a bluetooth pairing between the bluetooth module and a smartphone via NFC. For that, I am storing the address of the bluetooth module in the NFC EEPROM.

In this setup, the pairing process is unsuccessful (no message on the smartphone asking for pairing confirmation and no auto-connection).

For further understanding :

  • I tested the procedure on the ANT7-T-ST25DV64KC evaluation board and the pairing is successful.
  • I put the ST25DV64KC IC of the evaluation board on my custom board (with the bluetooth module) and the pairing is successful.
  • I put back the standalone ST25DV64 IC on the evaluation board, and the pairing is unsuccessful.
  • I tested on other same-series standalone ST25DV64 ICs and the pairing is unsuccessful.

So there is problem (configuration, hardware, ..) on the standalone ST25DV64  ICs that I have.

I compared the 2 ICs static configuration registers and there is no difference (no protection on user memory, same GPO management, ...).

I see a difference on what is marked on the IC. For the standalone IC, I have DV6DERBK134U and the IC on the evaluation board, I have DV6DERC237U. Are the 2 ICs different?

I futher investigated the basic RF operations on the 2 ICs using a NFC Tools application : I can read on both IC types, I can write on IC that was initially on the evaluation board but I can't write on the standalone IC.

 

Regards

Hi,

if I understand well, you would like to use the tag to store a bluetooth paring information (such as an NDEF pairing record) but you fail to populate this paring information into the tag and thus you cannot use it to pair your bluetooth equipment. 

Can you dump the content of the tag memory? Is your pairing information using NDEF format and is the tag NDEF formatted? When sending the WRITE SINGLE BLOCK command, what is the error code returned by the tag if any? 

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

I dumped the tag memory for the 2 tags : the one that allows BT NFC pairing and the one that doesn't allow BT NFC pairing. And it seems that the tag which doesn't allow BT NFC pairing was missing a header (highlighted red in the attached image). Is that the NDEF format? Is there a documentation that can give more information on the NDEF.

I also green-highlighted the bluetooth address that is written in tag.

Putting the header in the memory of the tag which was not pairing via NFC , makes it pair via NFC. Is that the solution?

 

Hi,

what you show in red is:

  • the Capability Container (CC) in block #0. The CC manages the information of an NFC Forum formatted Type 5 Tag
  • A part of the NDEF_Msg_TLV starting at block #1 with T = 03h, L = 2Bh and V being the content of the NDEF with a Bluetooth pairing record.

What you show in green is the last part of the Bluetooth pairing record (with the device address if i am not wrong).

The NDEF format is specified in the NFC Forum NDEF Technical Specification. 

In the factory all blocks of user memory are initialized to 00h (see ST25DV Datasheet). If NDEF is being used in your application, the CC and an empty NDEF have to be configured into the tag. See AN4911 (NDEF management with ST25DV-I2C Series) for detailed information.

It is likely that the tag is not NDEF formatted and that your application just writes the BT device address in the memory. Make sure to format the tag and make sure your application properly writes NDEF records. You can use the ST25NFCTap app on Android to check that the tag is properly formatted (see CC menu and NDEF menu).

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hi @Brian TIDAL 

Thanks for your answer. I can now pair to bluettoth devices using NFC and I understand better NDEF and NFC in general.

I have some further questions for better understanding :

  • What is the meaning of T and L in the TLV message?  AN4911 doesn't give more information
  • For the V-part of the NDEF, is the first part (before the device address) fixed?
  • Is there a documentation with more details on the formation of the NDEF message

Hi HABIJ.1,

I think you need to study the NFC Forum specs - especially on NDEF.

For TLVs I found some general information:

https://en.wikipedia.org/wiki/Type%E2%80%93length%E2%80%93value

 

Regards, Ulysses

Hi,

TLV stands for Tag-Length-Value (or Type-Length-Value). See Type–length–value for explanations. For an NDEF message, the T-field is 03h, the L-field is the length of the NDEF message and the V-field is the NDEF message.

The format of the bluetooth paring record is defined in the NFC Forum "Bluetooth Secure Simple Pairing Using NFC" application document. 

In your example, the payload seems to contain only the Bluetooth device address after the record type. This field is the first one after the Bluetooth OOB Data Length (08h 00h in your example)

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
HABIJ.1
Associate III

Thank you @Brian TIDAL and @Ulysses HERNIOSUS for the explanations and indications.