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

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

Michal — Tue, 04 Apr 2017 06:45:39 GMT

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.

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

CurtisHx — Mon, 03 Apr 2017 11:54:20 GMT

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.

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

Michal — Mon, 03 Apr 2017 09:56:00 GMT

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