NFC power consumption remains high after reading

RE: NFC power consumption remains high after reading

run_ar — Mon, 18 May 2020 09:52:40 GMT

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.

RE: NFC power consumption remains high after reading

mbeddeveloper — Wed, 13 May 2020 14:46:13 GMT

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

Is this issue solved in a newer SDK version?

RE: NFC power consumption remains high after reading

run_ar — Wed, 13 May 2020 14:36:45 GMT

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?

RE: NFC power consumption remains high after reading

mbeddeveloper — Thu, 07 May 2020 13:27:06 GMT

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)

RE: NFC power consumption remains high after reading

run_ar — Thu, 07 May 2020 13:21:32 GMT

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.