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 Simon,

    I'll try to explain everything from the beginning:

    My project is based on the nRF52832AA and SDK version 17.0.1.
    I built an application using this SDK without making any changes to the SDK files.

    Now, let me explain the issue:

    Sometimes, when the device remains on the NFC pad, it gets stuck.

    This means that the expected sequence does not occur, and after the watchdog timer expires, the device triggers an alarm.

    I've identified a few issues in the code.

    As shown in this picture of our board, the SDK is not configured to send the "Field Off" interrupt—only the "Field On" is enabled.

    In this picture, the handler safeguards against the case where a "Field On" event can occur without a corresponding "Field Off" event, using the m_nfct_cb.field_on flag.

    However, the "Field Off" event is never triggered or handled in this function.

    Instead of being called from the callback, we call it from the function below and reset m_nfct_cb.field_on.

    However, unlike the callback, we don’t check whether this value has already been reset.

    I prefer not to modify the SDK files, but something doesn't seem to be working correctly.

    After debugging, I noticed that sometimes the device receives two interrupts from nrfx_nfct_field_poll(), which causes it to get stuck. Occasionally, the device also hangs during the execution of this function—specifically before the call to nrfx_nfct_frame_delay_max_set(true);.

    Best regards,
    Hadar

Reply
  • Hi Simon,

    I'll try to explain everything from the beginning:

    My project is based on the nRF52832AA and SDK version 17.0.1.
    I built an application using this SDK without making any changes to the SDK files.

    Now, let me explain the issue:

    Sometimes, when the device remains on the NFC pad, it gets stuck.

    This means that the expected sequence does not occur, and after the watchdog timer expires, the device triggers an alarm.

    I've identified a few issues in the code.

    As shown in this picture of our board, the SDK is not configured to send the "Field Off" interrupt—only the "Field On" is enabled.

    In this picture, the handler safeguards against the case where a "Field On" event can occur without a corresponding "Field Off" event, using the m_nfct_cb.field_on flag.

    However, the "Field Off" event is never triggered or handled in this function.

    Instead of being called from the callback, we call it from the function below and reset m_nfct_cb.field_on.

    However, unlike the callback, we don’t check whether this value has already been reset.

    I prefer not to modify the SDK files, but something doesn't seem to be working correctly.

    After debugging, I noticed that sometimes the device receives two interrupts from nrfx_nfct_field_poll(), which causes it to get stuck. Occasionally, the device also hangs during the execution of this function—specifically before the call to nrfx_nfct_frame_delay_max_set(true);.

    Best regards,
    Hadar

Children
No Data
Related