Changes in NFC Type 4 library from SDK 12.2 to SDK 13?

[CurtisHx]

I see in the SDK 13.0.0 release notes that the NFC type 4 library was updated to "production ready", but I couldn't find a summary of the changes made to the NFC Type 4 library.

We're seeing an occasional problem with the NFC Type 4 library from SDK12.2.0. On write, the NLEN field will sometimes remain 0 after the write is done. Was this a known problem in 12.2.0 and was it fixed in 13.0.0?

[Michal]

Hi,

For SDK 13.0 no functional changes have been made in type 4 Tag lib. By upgrading to "Production Ready" we mean we focused on verification (mostly system- and integration-level) to improve the quality. To be precise we fixed some bugs in hal_nfc_t4t (e.g. NFC startup while HFCLK is running) and improved NFC-A symbol detection stability (by adjusting register settings) for nRF52840 devices.

Additionally, we added:

• static configuration (in sdk_config.h) of HAL_NFC_TIMER_PERIOD parameter used for workaround for errata [79] on nRF52832 devices,
• static configuration (in sdk_config.h) of NFC IRQ priority

When it comes to NLEN field remaining 0 after write - we haven't seen such an issue. Do you use any standard Reader/Writer (PCD) when this problem occurs? How can we reproduce such a case? Generally the way the library handles UPDATE_BINARY C-APDUs is that it checks the offset parameter, and if the offset <= 1 (meaning the NLEN field is being updated) it notifies the application with NFC_T4T_EVENT_NDEF_UPDATED

[Michal]

Ok, so it sounds like the issue with NLEN remaining 0 may appear due to low electromagnetic coupling between antennas and interrupting the actual communication. In this case, I think a way to recover would be to check the event sequence for NFC_T4T_EVENT_NDEF_UPDATED with NLEN = 0 then NFC_T4T_EVENT_FIELD_OFF. It may happen that the UPDATEBINARY APDU writing NDEF data was successful even if the last NLEN update didn't happen. In such case the written NDEF will be there in the buffer provided in nfc_t4t_ndef_rwpayload_set() so the application can validate it, and call nfc_t4t_ndef_rwpayload_set() once again with the re-calculated NLEN, or simply update the NLEN directly in the buffer. Maybe that helps, but it assumes NDEF is not corrupted.