NFC

Hi,

I'm using the nRF52832 with SDK version 17.0.1, and I'm experiencing an issue with NFC handling.

Sometimes, the NFC interrupt triggers two FIELD_OFF or two FIELD_ON events in a row.

After investigating the code, I found that instead of being called from the interrupt handler, the FIELD_OFF event is triggered from another function. I've attached all the relevant functions for reference.

In particular, one function only triggers the FIELD_ON event, while the FIELD_OFF call appears to be disabled.
Is there a specific reason for this behavior?

 

In this function, I see that there's protection preventing 'filed_off' from being called without 'filed_on', and vice versa. However, in this state, we don't call 'filed_off' at all.

After debugging, we found that 'filed_off' is called from this function. There's no protection in place, and sometimes the device gets stuck while executing it.

I’d like to know if you see anything wrong with this function and how I can fix it.
Thanks,

Parents
  • Hi

    I wonder if this could be related to one of the fixes introduced in the nRF5 v17.1.0 SDK where we introduced (among a couple other things) a behavior change to the nfc_t4t_done() function as well as a frame waiting time management logic to match the ISO-DEP timing requirements.

    Is there a specific reason you're working on the nRF17.0.1 and not the latest nRF5 SDK version? Note that the nRF5 SDK as a whole is in maintenance mode (per this blog post), and most bug fixes and features are being done in the nRF Connect SDK these days. 

    If you think this is a proper bug, I will report it internally and see what we can do about it, but I can't promise a quick resolution to this in the nRF5 SDK at this point I'm afraid.

    Best regards,

    Simon

Reply
  • Hi

    I wonder if this could be related to one of the fixes introduced in the nRF5 v17.1.0 SDK where we introduced (among a couple other things) a behavior change to the nfc_t4t_done() function as well as a frame waiting time management logic to match the ISO-DEP timing requirements.

    Is there a specific reason you're working on the nRF17.0.1 and not the latest nRF5 SDK version? Note that the nRF5 SDK as a whole is in maintenance mode (per this blog post), and most bug fixes and features are being done in the nRF Connect SDK these days. 

    If you think this is a proper bug, I will report it internally and see what we can do about it, but I can't promise a quick resolution to this in the nRF5 SDK at this point I'm afraid.

    Best regards,

    Simon

Children
No Data
Related