NFC hiding events?

[Lee Daniel Crocker]

I have software on my PC with an NFC reader attached, that connects to my nRF52 devices, reads the NDEF tag, modifies it, writes it back, then reads back the modified value. It works perfectly: it shows the value read, which I put into the firmware, it shows the good return code from the write command (0x90, 0x00), and then it shows the altered data on the second read.

The problem is that my firmware isn't seeing those events. I'm calling nfc_t4t_setup() with a callback function, and that callback function is seeing the field on/off events, and the first read event, but it is not seeing the update event or the second read. Is there some reason that the library is hiding these events from me? Clearly they are occurring, as as the write and second read are happenning and the data is changed. Am I missing something?

[Mttrinh]

Hi,

The NFC_T4T_EVENT_NDEF_READ is only reported once during one “session” i.e. between NFC_T4T_EVENT_FIELD_ON and NFC_T4T_EVENT_FIELD_OFF events. So if the tag was read, then written (data on the tag was updated), another read will not trigger the READ event, unless FIELD_OFF and/or FIELD_ON event comes. Unfortunately there is no way to change this event’s behavior without modifying the library’s source code. However we plan to release an updated Type 4 Tag library, with a fixed READ event in the next SDK release.

Regarding the NFC_T4T_EVENT_NDEF_UPDATED event, it’s very strange that you don't see these events. They are reported every time the NLEN field (2 most significant bytes of the NDEF file, representing the NDEF message length) is updated. There are typically 2 UPDATE events during a single tag write operation: first the NLEN is set to [0x00, 0x00] to indicate start of the write operation (first UPDATE event), then new data is written, and finally the NLEN is set to the length of the new NDEF message (second UPDATE event). Possible to upload the firmware so we can have a look at it? If this is sensitive code, the case can be turned private.

[Lee Daniel Crocker]

Sounds like it may have something to do with how I'm writing, then. On the other side, I'm sending ISO-7816 messages directly, and I'm only sending a single update (0xD6) command, overwriting the old text with one of the same length. I have since changed my firmware to look for the actual changed data so I don't need the callback anymore. If I have some time, I'll trim my firmware down to something uploadable and let you take a look.