Fundamental ST25DV64 Register Write problems

Brad Goodman · ‎2023-01-10

Am in the infancy of a proof-of-concept investigation with ST25DV64. I have been able to do some read/writes with NFC without issue - and am working on the i2c side.

We are working with a custom/proprietary system/i2c stack so I don't have much off-the-shelf code to fall back on, but I've written what seems to be a proper implementation of the basic register read/write protocols outlined in ST25DV64 datasheet - and they MOSTLY work.

I can read the NFC NDEF data via i2c from registers at i2c address 0x53, device addresses 0 - 32.I am also getting what appears to be valid Dynamic Configuration registers via device 0x53 register addresses 0x2000-2007 as such:

2000: 88 ff 08 00 00 00 00 00

Which seem to be a valid representation of the initial state of these registers. I can also write and modify one of the GPO bits and read it back

But here's where things get weird:

If I write like an 0x08 to location 2000 - it seems to turn off the high 8 bit. But If I write a 0xff I read back an 0x88. If I write a 0x00 - I always get a 0x08. In other words - I only seem to have control of the high bit in this register.

Write to 0x2002 or 0x2003 will get acked back - but 0x2006 does not.

I can verify with the i2c decoder on my scope that at least the scope believes the signals are good, and I have bumped the I2C speed up and down orders of magnitude (and although at some levesls this stops working) - this specific behavior of these registers remain unchanged.

From what I can tell - these are the first registers that I should be writing to enable other functionality in other registers.

Is there a signaling problem here, or an I doing something complete wrong?

Brad Goodman · ‎2023-01-25

Are there any "best practices" or recommendations to achieve two-way back-and-forth interfactions between ST25DVxx and an initiator?

For example I can have a device read, write, or use a custom command to write a message (mailbox) to the chip, The chip can get an interrupt, read the mailbox, do something and return a result. But as for the device on the other (RF) end - it can't get an "interrupt". The best I've been able to make out is a mandatory wait before it's subsequent readback - and a check of the resulting payload to make sure it's a new, complete message from the I2C side.

I am assuming there is no way to do any kind of interrupt or "blocking" read operation from an RF device (such as a smartphone), is there?

Are there any ways or techniques I should be doing to better leverage this - beyond a wait, poll and poll again?

JL. Lebon · ‎2023-01-26

As you understood, there is no kind of interrupt on the RF side. NFC is just made like that and this kind of feedback to RF is not included in the protocol.

So, the only solution is polling.

For normal data exchange through EEPROM memory, there is no other choice than read the content regularly to check for an update. One technic is to dedicate a block address to be a "Synchro" block. When each side is writing data into the EEPROM, it always ends it's write by updating the value of this synchro block. So, the other side just has to regularly read this synchro block to know if the content of memory has been changed.

In the ST25DV, the best way to do this is to use Fast Transfer Mode and exchange data through the mailbox. In Fast transfer mode, the "synchro block" is embedded in a form of a status register. Each time an interface (I2C or RF) writes or reads a message in the mailbox, this status register (MB_CTRL_Dyn) is updated. So the RF has to do polling on this register to know if there is a new message to read or to write into the mailbox. There is several flags into this register that indicate if there is a message, if the message if from RF or I2C and if the message is still valid or obsolete.

Hope this helps.

Best regards.

Brad Goodman · ‎2023-01-26

Thanks - that makes sense.

Are you implying the "synchro block" should be in eeprom and not a mailbox? (Due to the mailbox being singular, in that you have to write your whole message out from zero each time?) Or could my "syncro block" be the first x bytes of the mailbox?

JL. Lebon · ‎2023-01-26

If you are using the mailbox to transfer data between RF and I2C, you don't need a synchro block as it is already present in the form of the MB_CRTL_Dyn register.

If you are using the EEPROM to exchange data, then you can use a synchro block. You may then use an EEPROM memory block (but be careful on cycling on this block), or as you suggest, you can write a "synchro message" in the mailbox. But using EEPROM and mailbox at the same time is constraining: when FTM is enabled (MB_CTRL_Dyn[MB_EN]=1), it is not possible to write into EEPROM. So you would need to enable FTM when writing synch message and disabling it again when you want to write into EEPROM.

Best regards.

Brad Goodman · ‎2023-01-26

Are you saying that my RF (phone) should be polling MB_CTRL_Dyn, directly, to see if there is an i2c-generated message awaiting receipt?

JL. Lebon · ‎2023-01-26

If you are doing transfer via the mailbox (i.e. your I2C controller is writing messages into the mailbox), then yes, the right procedure for the RF reader is to read (polling) the MB_CTRL_Dyn register to know if there is a message from I2C available in the mailbox.