Determine the end of an NFC Write?

[CurtisHx]

Is there a way to determine the end of an NFC write besides waiting for the NFC_T4T_EVENT_FIELD_OFF event? We want to update the NDEF message from within firmware after data is written but before the NFC_T4T_EVENT_FIELD_OFF event fires. We tried doing the update on NFC_T4T_EVENT_NDEF_UPDATED when data_length is greater than 0 in nfc_callback, but that doesn't work.

UpdateNdefMessage reads the ndef message that was just written to the device, and then updates the ndef message based on what was written.

Is there a way to determine when a write is finished without relying on NFC_T4T_EVENT_FIELD_OFF?

	static void nfc_callback(
  void          * context     __attribute__((unused)),
	nfc_t4t_event_t event       __attribute__((unused)),
	const uint8_t * data        __attribute__((unused)),
	size_t          dataLength  __attribute__((unused)),
	uint32_t        flags       __attribute__((unused)))
{
	switch (event)
	{
	case NFC_T4T_EVENT_NDEF_READ:
		break;
	case NFC_T4T_EVENT_NDEF_UPDATED:
		if (dataLength > 0)
		{
			UpdateNdefMessage();
		}
		break;
	default:
		break;
	}
}

[Michal]

Let me add a couple of details regarding the NFC_T4T_EVENT_NDEF_UPDATED event:

• it will only be triggered if the NDEF content was set as Read/Write i.e. using nfc_t4t_ndef_rwpayload_set - is it how you set it in your application?

• the event is triggered each time the UPDATE_BINARY APDU is received with offset <= 1 (NLEN field)

Additionally, do you get any NFC_T4T_EVENT_NDEF_UPDATED event, e.g. when the Reader/Writer (PCD) clears the NLEN field? For short messages, some PCD could write NLEN together with the rest of the NDEF content (as part of a single UPDATE_BINARY Command APDU)

Also, is the write operation successful at all?

[CurtisHx]

The NDEF content is set as Read/Write. We get 2 NFC_T4T_EVENT_NDEF_UPDATED events every time we write. The data_length parameter is 0 on the first write, and is the written NDEF message length on the second write. The write operation is successful on the nRF52. However, the application side (we're using NFC Tools on Android phones) reports back with a generic write error.

[Michal]

Then to me it looks OK on the nRF52 side. Regarding the phone side - is the error reported consistently on different phones? We have seen some variation between different phones, but generally NFC Tools seemed stable. Can the NFC Tools read back the newly written content even if reported an error on the Write operation?

[CurtisHx]

It's consistent across phones. The NFC Tools doesn't read back the newly written content because the UpdateNdefMessage function writes over the NDEF buffer within the NFC Type 4 library.

[CurtisHx]

We came up with a work-around. We configured a hardware timer to fire its interrupt a few milliseconds after the last NFC_T4T_EVENT_NDEF_UPDATED event, and do all of the NDEF reconfiguration in there. That solved our problem.

[Michal]

Good that your workaround seems to work.

The only issue I can see with using NFC_T4T_EVENT_NDEF_UPDATED is that UpdateNdefMessage might take long to execute and thus prevent from sending R-APDU (response to UpdateBinary) in time. This is because the callback for NFC_T4T_EVENT_NDEF_UPDATED event is called before sending the proper R-APDU. Other than that, I can't see why updating the NDEF content like you did originally, would not work, maybe some sniffer log could tell us more.