2021-03-17 08:46 AM
Hi
I met a problem with generating a single interrupt after an NDEF message is written to the tag.
I have managed to change the GPO register to 0b11000000, which means the interrupt should only happen when a successful RF-write is performed.
However, the interrupt is generated as long as I put my phone near the tag, which based on my understanding should correspond to FIELD_CHANGE_EN=1. But I have checked the GPO register and FIELD_CHANGE_EN=0.
I have also checked the interrupt signal with a logic analyzer. During NDEF message writing, there are multiple pulses generated by the chip.
I don't know what is wrong, any suggestions?
I have attached the main.c file in the post.
Thank you guys in advance.
Yuechuan
Solved! Go to Solution.
2021-03-18 10:48 AM
Hi @YLin.2 ,
Nothing is wrong in fact. The tag is sending a pulse on the GPO pin each time the Reader(smartphone in your case) writes in the memory. Readers can't write the NDEF file in one command (defined in the standard), they can write only 1 block at a time (and 1 block is composed of 4 bytes). There is maybe some extended commands that could write more than 4 bytes but if I'm not wrong Android is not using it.
And in second point, to write an NDEF message you need first to set the size field of the NDEF message to zero, write your message then fill the length field with the correct size. This is something described in the standard so it will not be possible to bypass that and smartphones are operating like that too.
So if you want to know when the NDEF message has been written, you need to read the length at each interruption to know if the length is different from 0. But be careful to not have arbitration conflicts between I²C and RF. Another solution is to set a timeout, resets this timeout each time the interrupt raised and when the timeout is exceeded read the length.
Hope this can help you.
Best regards.
2021-03-18 10:48 AM
Hi @YLin.2 ,
Nothing is wrong in fact. The tag is sending a pulse on the GPO pin each time the Reader(smartphone in your case) writes in the memory. Readers can't write the NDEF file in one command (defined in the standard), they can write only 1 block at a time (and 1 block is composed of 4 bytes). There is maybe some extended commands that could write more than 4 bytes but if I'm not wrong Android is not using it.
And in second point, to write an NDEF message you need first to set the size field of the NDEF message to zero, write your message then fill the length field with the correct size. This is something described in the standard so it will not be possible to bypass that and smartphones are operating like that too.
So if you want to know when the NDEF message has been written, you need to read the length at each interruption to know if the length is different from 0. But be careful to not have arbitration conflicts between I²C and RF. Another solution is to set a timeout, resets this timeout each time the interrupt raised and when the timeout is exceeded read the length.
Hope this can help you.
Best regards.
2021-03-18 06:08 PM
2021-03-19 12:42 AM
Hi @YLin.2 ,
Normally, if you have enabled an RF write only on the GPO, the ST25DV should send a pulse only when a write command is sent from the Reader (and the pulse is sent when the write has completed). For the RF there is 2 separated commands, one for the read and one for the write. The RF read command doesn't generate a GPO pulse.
With Android phones, one thing to consider is that natively, Android is scanning for NFC tags every time (when NFC is activated of course). But it should only send read commands and not write commands, so the GPO should not move.
One precision on the I²C, is that when you send the read command the address you're writing is memorized in the I²C IP register not in the EEPROM (otherwise it would take longer for a read, a write to EEPROM takes 5 ms for 1 page 1 to 4 bytes).
So to come back to your question, if the only interrupt configured is the RFWrite, the GPO will react to the RFWrite command only. Moving the phone will not generate GPO pulses in that case, there are probably some write commands that are sent I guess. If you can Debug, try to add breakpoints on the "transmit" function to check it.
Best Regards.
2021-03-19 09:11 PM
HI @Rene Lenerve
I found the source of the problem. It is that I need to pull-up the GPO pin since it is open-drain. Now the interrupt is generated as expected!