2024-07-03 08:03 AM
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
Solved! Go to Solution.
2024-07-04 01:17 PM
Hi,
what you show in red is:
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
2024-07-03 08:07 AM
Hi,
can you show which command is being sent to write?
Rgds
BT
2024-07-04 06:00 AM - edited 2024-07-04 07:00 AM
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 :
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
2024-07-04 06:33 AM
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
2024-07-04 08:48 AM
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?
2024-07-04 01:17 PM
Hi,
what you show in red is:
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
2024-07-08 07:22 AM
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 :
2024-07-08 08:41 AM
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
2024-07-08 08:42 AM
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
2024-07-09 12:38 AM
Thank you @Brian TIDAL and @Ulysses HERNIOSUS for the explanations and indications.