Fundamental ST25DV64 Register Write problems

[Brad Goodman]

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?

[Ulysses HERNIOSUS]

Hi,

did you check the DS? I find:

which IMO backs your observations.

Regards, Ulysses

[Brad Goodman]

Which DS is this??? It looks very different than the one I have!

[Ulysses HERNIOSUS]

https://www.st.com/resource/en/datasheet/st25dv64k.pdf

[Brad Goodman]

Interesting - the hyperlink for that field goes to the table in the next page - so I never noticed that section on the previous pagethat marked b0-b6 as RO!

[Brad Goodman]

So - I am trying to write to Fast Mailbox Transfer at address 0x2008, and am getting errors. THe obvious culprit would be that I need to enable FTM by writing a 0x01 to address 0x2006. But when I do this - I always get an error (NAK). Is there something more to this that I am missing, or should this alone work?

[JL. Lebon]

Hello,

Yes, you first need to enable FTM to be able to write into the mailbox.

To enable FTM, this is in fact a two steps process.

You first need to authorize FTM: this is done by writing MB_MODE=1. This is a non-volatile configuration register (I2C address 0x000D in the system memory) so you only need to write it once.

Then only, you will be able to write MB_CRTL_Dyn register to 0x01 (address 0x2006) to enable the mailbox access.

Be aware that once the mailbox is enabled, you can write at address 0x2008, but you can't write anymore in the user memory (EEPROM). You first need to disable the mailbox to be able to write again in EEPROM.

Best regards.

[Brad Goodman]

Thanks - this helps a LOT!

But I must say - the docs are very unclear. Specifically it lists the MB_CTRL_Dyn register as "b0: R always, W always b7-b1: RO"

And goes on to say "MB_EN bit is automatically reset to 0 if MB_MODE register is reset to 0."

So this had me going nuts trying to figure out HOW TO Enable FTM - as it was telling my how to clear this bit but not how to set it, and strongly implying that the "Enable FTM" bit was read-only.

[Brad Goodman]

I'm plugging along well - but am having serious issue with GPO. i.e. The pin seems to be just giving me noise (when I do i2c transactions) i.e. it seems like it's High-Z.

I'm (still) a little confused by the docs (as most of these registers are read-only and it's unclear at least as of yet how to specify things more clearly) - but - the GPO_EN is set on both the GPO and GPO_CTRL_Dyn registers - so - do I have a hardware problem, or is there another register I am missing? I have a pullup on the line which is pulling-up - but I'm getting some noise on the GPO line any time I do an i2c transaction. As I read it - I should ONLY be getting a signal during RF???

i2c-tools> i2cbkg -c 0x57 -r 0x0 -l 16
READ 16 bytes from Addr 0x0 Device 0x57
0000: 80 03 01 00 00 3f 00 3f 00 3f 00 00 00 01 07 00 
OK
READ 16 bytes from Addr 0x2000 Device 0x53
2000: 80 ff 08 00 01 00 a1 53 ff 00 55 aa 66 69 72 73 

[JL. Lebon]

Hello,

To use GPO, you need to do 2 things in SW:

• Enable the GPO output: this is done by setting bit GPO_EN=1 in both the GPO static configuration (i2c address 0000) and the GPO_CTRL_Dyn regsiter (i2c address 2000). Please note that depending on the version of the ST25DV you have, this bit may be at different location in the Byte (ST25DV64K: GPO_EN is bit 7, ST25DV64KC: GPO_EN is bit 0)
• Enable an interrupt on the GPO pin: the GPO pin to toggle on an event or a RF command. You need to enable the corresponding event. This is done by setting the corresponding bit in the GPO static configuration (i2c address 0000)

In your case, the GPO static configuration is set to 0x80, which means that GPO output is enabled, but no interruption is enabled. So the GPO pin will always stay at the pull-up level.

You also need to have the correct HW setting. There is again 2 versions of ST25DV: the -IE version, which has an open-drain GPO output (8 pins package version), and the -JF version which have a push-pull GPO output (this one is 12 pins package version). If you have the 8 pins package version which is open-drain, you need to have a pull-up resistor (~15k) tied to Vcc connected to GPO. If you have a 12 pins package, you need to connect a power supply to the VDCG pin and no pull-up.

Best regards.

[Brad Goodman]

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]

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.