This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NFC tag stops working suddenly in very rare cases

We are using nRF52840 on a custom board with nRF5 SDK v15.3.0.

Our application uses the NFCT driver (nrfx_nfct) along with nfc_t2t_lib_gcc.a to emulate a NFC tag with some text records. I am using an Android phone to read the tag. This is working fine most of the time. But in very rare cases the NFC tag stops working suddenly and cannot be read anymore. Only a Reset helps.

If I enable the debug build (DEBUG_NRF macro), the processor runs into an assertion in nrf_drv_clock.c, line 328 ( ASSERT(m_clock_cb.hfclk_requests > 0); ). After a long debug session I found out, that in the error case the NFCT driver sends 2 times in a row the NRFX_NFCT_EVT_FIELD_LOST event. This event is handled in nfc_platform.c and calls nrf_drv_clock_hfclk_release(). This leads to the assertion in nrf_drv_clock.c, because the hfclk_requests counter is decremented twice.

The reason, why the NRFX_NFCT_EVT_FIELD_LOST event occurs twice, is that the NFCT IRQ handler got a FIELDDETECTED and a FIELDLOST IRQ at the same time. The handler ignores the FIELDDETECTED IRQ and just handle the FIELDLOST IRQ. Since the field was already off and the HF clock was already released, a second HF clock release leads to the error.

A possible solution for this bug is to add an if clause, which checks the field state in the nrfx_nfct_field_event_handler()  function, like this:

        case NRFX_NFC_FIELD_STATE_OFF:
            if (m_nfct_cb.field_on)
            {
                nrfx_nfct_state_force(NRFX_NFCT_STATE_SENSING);
#ifdef NRF52840_XXAA
                /* Begin: Bugfix for FTPAN-116 (IC-12886) */
                if (m_nrf52840.eng_a)
                {
                    *(volatile uint32_t *)0x40005010 = 1;
                }
                /* END: Bugfix for FTPAN-116 (IC-12886) */
#endif // NRF52840_XXAA
                nrf_nfct_int_disable(NRFX_NFCT_RX_INT_MASK | NRFX_NFCT_TX_INT_MASK);
                m_nfct_cb.field_on = false;
                nfct_evt.evt_id    = NRFX_NFCT_EVT_FIELD_LOST;
    
                NRFX_NFCT_CB_HANDLE(m_nfct_cb.config.cb, nfct_evt);
            }
            break;

Is this bug is already known?

I guess this bug is also present in older SDK's.

  • Hi,

    I'm suspecting that the issue might be related to this errata for the nRF52832. Is TASK_SENSE triggered right before the FIELDDETECTED event occurs? 

    regards

    Jared 

  • Hi Jared,

    Yes, this is working fine.

    The problem is really in the NFCT IRQ handler. Only one field event is handled (field detected or field lost) at once, even if both events has occurred. This can cause the lost event to be handled twice in a row. The first time, when the filed is gone. And the second time (later in time), when the field was there for a really short time and both events were handled in the same IRQ handler call. In this case nrf_drv_clock_hfclk_release() was called one time too much, which leads to an assertion.

    It is really a bug in the NFCT driver. It can be fixed as described.
    It happens very, very rarely. Therefore it is difficult to reproduce.

    I hope, my explanation is clear enough...

    Regards,
    Timo

  • Hi,

    Thank your for a great explanation of the problem

    timo151 said:
    It happens very, very rarely. Therefore it is difficult to reproduce.

    What happens when the issue doesn't reproduce? Is the problem that it's difficult to generate FIELDDETECTED and a FIELDLOST event simultaneously, or is that the driver sometimes doesn't ignore the FIELDDETECTED event which doesn't cause the bug to happen? In other words, are you seeing the bug every time the FIELDDETECTED and FIELDLOST event is generated simultaneously? 

    I would have to reproduce the issue before i could report it as a bug. Could you share a project that would be able to reproduce the issue sometimes and can run on the DK , and could you give a rough estimate % wise of how frequently you're seeing this bug?

    regards

    Jared 

  • Hi,

    Yes, I am seeing the bug every time the FIELDDETECTED and FIELDLOST event is generated simultaneously. When these event are not generated simultaneously, there is no issue.

    The problem to reproduce is that it's difficult to generate FIELDDETECTED and a FIELDLOST event simultaneously. You can increase the probability of error case, if you spend more time in interrupts (e.g. add a delay in an interrupt handler --> I added a 10ms delay at the end of nrfx_nfct_irq_handler to reproduce it). Then you have to read the NFC tag multiple times with a mobile phone.

    You can use an example of the nRF5 SDK v15.3.0, e.g. examples\nfc\record_text. Add the macro DEBUG_NRF to the Makefile in order to see the assertion. It also helps, when you enable the log in nrfx_nfct.

    RTT Viewer output, when the error occurs:

    0> <debug> NFCT: Field detected
    0> <debug> NFCT: Field lost
    0> <debug> NFCT: Field detected
    0> <debug> NFCT: Field lost
    0> <error> app: ASSERTION FAILED at ../nRF5_SDK_15.3.0_59ac345/integration/nrfx/legacy/nrf_drv_clock.c:328

    Regards,
    Timo

  • Hi.

    Sorry for the late reply.

    Thank you for a good explanation of both the bug and the steps for reproducing it. I've reproduced the bug and have reported it. I assume that it will be fixed in a future release.

    Best regards

    Jared 

Related