Question related to [218] NFCT: Frame Delay timing is too short after SLP_REQ.

RE: Question related to [218] NFCT: Frame Delay timing is too short after SLP_REQ.

Sigurd — Tue, 25 Aug 2020 14:41:25 GMT

You need to somehow ensure that FRAMEDELAYMAX is set to the default value when the NFCT is in states IDLE or SLEEP_A. There are several major changes in NFC drivers/libraries since SDK 15.2. E.g. in SDK 15.3 we have this section in the release notes:

- The NFC libraries (nfc_t2t_lib and nfc_t4t_lib) now use the NFCT driver instead of the NFC HAL modules (hal_nfc_t2t and hal_nfc_t4t). 
  The NFCT driver is a part of nrfx repository.
- Replaced hal_nfc_t2t and hal_nfc_t4t components with the nrfx_nfct driver.
- Added the NFC platform module (nfc_platform) to abstract runtime environment specific implementation from the driver.
  HFCLK activation, required for NFC to operate correctly, is managed in this module.
- Removed the nfc_fixes.h file with NFC workaround description. The content of this file was moved to nrfx_nfct.h.

So backporting the workaround shown in SDK 16 to SDK 15.2 is actually not straight forward after all. If you are having difficulties with implementing the workaround in SDK 15.2, it might be easier to migrate your code to use SDK 16 instead.

RE: Question related to [218] NFCT: Frame Delay timing is too short after SLP_REQ.

pd@learner — Thu, 13 Aug 2020 18:21:45 GMT

is there any other way to ensure this?

RE: Question related to [218] NFCT: Frame Delay timing is too short after SLP_REQ.

Sigurd — Tue, 11 Aug 2020 08:36:59 GMT

[quote user="pd@learner"]I am using SDK 15.2.0[/quote]

Ok, in that case you would need to backport the workaround from SDK 16, to SDK 15.2

RE: Question related to [218] NFCT: Frame Delay timing is too short after SLP_REQ.

pd@learner — Mon, 10 Aug 2020 11:08:17 GMT

I am using SDK 15.2.0 and softdevice s132 v6.1.0

RE: Question related to [218] NFCT: Frame Delay timing is too short after SLP_REQ.

Sigurd — Mon, 10 Aug 2020 11:06:42 GMT

Hi,

As mentioned in the errata document, the workaround is included in nRF5 SDK v16.0. So if you are using SDK 16.0 or SK 17.0, the workaround is already included. The workaround is used e.g. here, and other places inside nrfx_nfct.c.