2025-09-01 10:32 AM
I am facing difficulties configuring the GPO interrupt on the ST25DV04KC to trigger exclusively when an NDEF message is written to the tag via the RF interface. The NDEF formatting is working correctly, and I am able to read and write data without issues both through the RF interface and via my microcontroller using the I2C protocol. However, I have not found a configuration or register setting that allows the GPO to generate an interrupt solely upon an NDEF write event initiated from the RF side.
The interrupts are only working if I configure them as shown below.
NFC07A1_NFCTAG_ConfigIT(NFC07A1_NFCTAG_INSTANCE, ST25DVXXKC_GPO1_ENABLE_MASK | ST25DVXXKC_GPO1_FIELDCHANGE_MASK);
However, in this configuration, as expected, the interrupts are triggered simply by bringing the RF device close to the tag, without performing any read or write request. Therefore, this behavior does not serve the intended purpose.
I tried the configurations below but was not successful. Shouldn’t this work?
NFC07A1_NFCTAG_ConfigIT(NFC07A1_NFCTAG_INSTANCE, ST25DVXXKC_GPO1_ENABLE_MASK | ST25DVXXKC_GPO1_RFWRITE_MASK);
or
NFC07A1_NFCTAG_ConfigIT(NFC07A1_NFCTAG_INSTANCE, ST25DVXXKC_GPO1_ENABLE_MASK | ST25DVXXKC_GPO1_RFPUTMSG_MASK);
When I configured it this way, no interrupts were generated anymore, whether writing, reading, or even bringing the device close to the ST25DV’s RF field.
My main goal is to generate interrupts only when the device writes an NDEF message or reads the NDEF, and to find a way to differentiate between these two interrupts. Is this possible? Could you suggest a way to achieve this?
Thank you.
Solved! Go to Solution.
2025-09-03 7:44 AM
Hello,
The command to configure the IT seems correct. Nevertheless, several problems can cause the absence of the IT pulse during the write:
- the configuration of the IT may have failed. For the configuration to be written correctly, the security session must first be opened (by presenting the password). If this is not done, the configuration is not updated. Can you please check that the configuration is written correctly (just read GPO1 and check that the bits 7 and 0 are set)?
- there is no write into EEPROM. Indeed, the RF_WRITE IT occurs only if there is a write into EEPROM. Any write in a Dynamic register or in mailbox do not trigger the IT. The lists of RF command that may trigger the IT is available in the datasheet (chapter 5.4 GPO). I guess you are writing the NDEF into user memory, that is EEPROM, so you are probably ok with this.
- the write into EEPROM failed. The RF_WRITE IT is triggered only if the RF write into the EEPROM is valid and successful. Is your RF write command answered with no error?
- there is no pull-up on the GPO pin (Open drain version) or no voltage on VDCG (CMOS version). Iin that case, the IT is triggered, but not visible on the output. But I guess you are ok with this since you saw the interrupt when RF field is rising.
Can you please check all those possible errors?
Best regards.
2025-09-03 1:56 AM
Hello,
There is actually no built-in interrupt to detect the NDEF write. But it is possible to "build" one.
For that you need to use the RF_WRITE interrupt. Once this interrupt is enabled, the GPO will output a pulse each time the reader writes into the EEPROM.
The trick to read the NDEF TLV each time the RF_WRITE interrupt is triggered, and check if the L value has been changed from 0 to something different from 0.
The NDEF write procedure as defined by the NFC Forum specification says that each time a NDEF is written, the reader must first set the L value of the TLV to 0, then write the NDEF message, and then write the correct length value in the L of the TLV.
So, by checking at each EEPROM write is the TLV value has been changed from L=0 to L>0, you can detect that the NDEF has been written.
Be aware that you have to take into account that TLV position can be different depending on the CC File length and that the L can be coded on 1 or 2 bytes.
The interrupt service routine should be fast, so that the I2C read of the TLV is done between 2 RF accesses to avoid collisions between RF and I2C.
For the NDEF read detection, there is no interrupt that can be useful, so it is not possible.
Best regards.
2025-09-03 4:46 AM
Hi Lebon,
Thank you for your reply.
Indeed a functional RF_WRITE interrupt would be enough to detect the writing on the tag, and I could check the NDEF TLV without any problems, but as I mentioned I don’t get any interrupt when I enable the interrupt using RF_WRITE. Am I doing this wrong?
#define ST25DVXXKC_GPO1_ENABLE_MASK (uint8_t)0x01
#define ST25DVXXKC_GPO1_RFWRITE_MASK (uint8_t)0x80
NFC07A1_NFCTAG_ConfigIT(NFC07A1_NFCTAG_INSTANCE, ST25DVXXKC_GPO1_ENABLE_MASK | ST25DVXXKC_GPO1_RFWRITE_MASK);
When I configure it this way, I don’t get any interrupt when writing to the tag, either with the ST application or with my custom application.
Best regards.
2025-09-03 7:44 AM
Hello,
The command to configure the IT seems correct. Nevertheless, several problems can cause the absence of the IT pulse during the write:
- the configuration of the IT may have failed. For the configuration to be written correctly, the security session must first be opened (by presenting the password). If this is not done, the configuration is not updated. Can you please check that the configuration is written correctly (just read GPO1 and check that the bits 7 and 0 are set)?
- there is no write into EEPROM. Indeed, the RF_WRITE IT occurs only if there is a write into EEPROM. Any write in a Dynamic register or in mailbox do not trigger the IT. The lists of RF command that may trigger the IT is available in the datasheet (chapter 5.4 GPO). I guess you are writing the NDEF into user memory, that is EEPROM, so you are probably ok with this.
- the write into EEPROM failed. The RF_WRITE IT is triggered only if the RF write into the EEPROM is valid and successful. Is your RF write command answered with no error?
- there is no pull-up on the GPO pin (Open drain version) or no voltage on VDCG (CMOS version). Iin that case, the IT is triggered, but not visible on the output. But I guess you are ok with this since you saw the interrupt when RF field is rising.
Can you please check all those possible errors?
Best regards.
2025-09-08 10:37 AM
Hi Lebon,
Thank you for the suggestions, after checking each one of them I was able to identify that the problem is in our NFC application. I confirmed that with the ST NFC TAP the write interrupt works as expected.
To close this topic, if I enable both the write interrupt (RFWRITE_MASK) and the RF field detection interrupt (FIELDCHANGE_MASK), is there another way to identify the source of the interrupt without looking at the L value of the TLV?
My intention is only to be able to differentiate an RF write interrupt from just an RF device approach, I believe that is enough for my goal.
Best regards.
2025-09-09 12:36 AM
Hello,
There is a status register that provides you the information of the interrupt source.
Each time the MCU receives an interruption, the interrupt service routine should read the IT_STS_Dyn register.
This register indicates which interrupt has been triggered. Each time an interrupt is triggered, the corresponding bit is set in this register.
This register is cleared only when it is read. So, it is important to read it each time an interrupt is received since a new bit is set each time a different interrupt is triggered, ending in several bits sets if not read frequently enough.
You can use this register to determine if the received interrupt is due to RF field detection or to RF write operation.
The read of the L value of TLV is just a trick to determine the end of the write of the NDEF.
Best regards.