NFC power consumption remains high after reading

[mbeddeveloper]

We are using a BLE module EYSHSNZWZ from Tayio Yuden which contains the nRF52832.

using SDK 15.0.0_a53641a and Softdevice and Softdevice s132_nrf52_6.1.0

The application initializes a type 4 tag (using the SDK) with a single NDEF message.

Before reading the Tag, the current consumption is around 10uA, which is fine.

When reading the NFC tag with a smartphone, the current increases to 3.1mA. If the smartphone is removed, the current stays at this value.

Investigations showed, that some chip-revisions showed a problem with the FIELDLOST event of the NFCT periphery. Adding the preprocessor symbol HAL_NFC_ENGINEERING_BC_FTPAN_WORKAROUND ot the project, solved the problem. But we think that there should be a "better" solution for this.

Maybe handling the FIELDLOST event somewhere in the software, to put the NFCT back to SENSE state and release the HFCLK.

Any hints how this problem should be handled would be helpful.

NFCT Documentation

NFC fixes

[run_ar]

Hi,

Not sure why you say there should be a better solution than adding the HAL_NFC_ENGINEERING_BC_FTPAN_WORKAROUND to the project. I think we have done a similar fix for this in our newer sdk. not adding the preprocessor symbol, but adding the workaround to the hal t4t file for all chips. I will have to check if we have a fix for sdk 15.0 or if you can use the one we have in a later sdk or something else. I will come back to you regarding that within a couple of days.

[mbeddeveloper]

Because in the Nordic examples the HAL_NFC_ENGINEERING_BC_FTPAN_WORKAROUND is not defined. Therefore maybe another solution is implemented there (that we, despite investigating, may have overlooked). 

And from the symbol you could derive that it is valid for chip revision B and C and not for the newer ones (1 and 2 are currently available)

[run_ar]

So it's probably better to manually change the hal_nfc_t4t.c file to include the workarounds for HAL_NFC_ENGINEERING_BC_FTPAN_WORKAROUND only for the nfc part. But still checking if we have a fix that can be used with sdk 15.0.

Would you be able to update to a newer SDK if required?

[mbeddeveloper]

Yes, we would be able to switch to a never version.

Is this issue solved in a newer SDK version?

[run_ar]

Hi,

Sorry there was a lot of back and forth. Seems in SDK 15.0 -15.2 the HAL_NFC_ENGINEERING_BC_FTPAN_WORKAROUND define was added based on board type. So if you have a custom board this was not enabled as it should have been. So you can continue keeping HAL_NFC_ENGINEERING_BC_FTPAN_WORKAROUND in your preprocessor symbols and use sdk 15.0 if you prefer.

Depending on how far you have come in your development cycle I would usually recommend using the latest sdk version as that has the most bugfixes. But if you have a done a lot of development and testing around sdk 15.0 I do understand if you would be reluctant to upgrade.