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

[CurtisHx]

We've been using Android smart phones ( Motorola X Pure and Samsung Galaxy S7) for all of our testing. It looks like it only shows up when there isn't a solid connection between the PCD and the nRF52832. I haven't seen this problem show up on the dev kit. Our device has pretty small antennal (18mm diameter) and we're still trying to fine tune the resonance. It's like the first NFC_T4T_EVENT_NDEF_UPDATED event succeeded, but the second event didn't happen.

[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.