NFC deadlock problem

[Frog]

I'm attempting to create and then update some NFC data to be presented as a type 2 device.

When I call nfc_t2t_payload_set it returns -45 (EDEADLK) but since the library is closed-source I can't debug any further.  Can you please advice what the conditions are that could cause this?  I've had success with example code but my application is relatively complex and I don't know what might be interacting.

In my .conf file I have

CONFIG_NFC_T2T_NRFXLIB=y
CONFIG_NFC_NDEF=y
CONFIG_NFC_NDEF_MSG=y
CONFIG_NFC_NDEF_RECORD=y
CONFIG_NFC_NDEF_TEXT_RECORD=y

Thanks,

  Frog

[Frog]

I've copied the code that builds the NFC message into an NFC example and can't replicate the problem, so I suppose the deadlock has to be related to something else in my (somewhat complex) firmware.  However, I don't have any other code that accesses the NFC hardware or libraries, so do you know what kind of resource the NFC code might be competing for?

[AHaug]

Hi,

Frog said:

do you know what kind of resource the NFC code might be competing for?

I can not say for certain without familiarizing myself with your firmware. As you've implied, a deadlock typically occurs when two or more operations are competing for the same resource such as a thread, so one option to debug this is to add LOGGING functionality to your firmware and breakpoints and debug to see where the function that causes the lock breaks. Here is also a course topic from our academy if you're unfamiliar with the logging functionality.

Another option to avoid dead locks is to make your application thread safe (wikipedia + course topic 7 and 8) which might require you to rethink and redesign some of your firmware w.r.t. how you want the flow of operation to be.

If you get any other log output when debugging, please share them with me and I'll have a look to see if I can identify what might cause the issues.

Kind regards,
Andreas 

[Frog]

Hi Andreas,

  Thanks for your reply.

I'm satisfied that there are no deadlock issues in the firmware that I have access to.  My question is not so much about what situations can lead to deadlocks, rather what resources specifically might the closed-source NFC library be competing for.

To answer your question "Have you confirmed that it is caused by the function call nfc_t2t_payload_set() or something else?" all I can say is that the EDEADLK is returned when I call nfc_t2t_payload_set().

Intriguingly, even though the calls to nfc_t2t_payload_set() return this error code, the NFC output data do get updated.

What I'm doing (perhaps a clue) is updating the NFC data that I need to be transmitted and re-submitting the same buffer each time.  I have tried nfc_t2t_payload_set(NULL, 0) to get the NFC library to release the buffer before re-submitting it, but this too returns -EDEADLK.

I've not been able to find any Kconfig settings that allow me to request more detailed information from within the NFC library.

Thanks,

  Frog

void nfc_update(void)

{

    uint32_t len = sizeof(ndef_msg_buf);

    int err;

    err = nfc_t2t_payload_set(NULL, 0); // release the buffer before updating it

    if (err < 0)

    {

        printk("Cannot release payload!\n");

    }

    err = nfc_msg_encode(ndef_msg_buf, &len);

    if (err  < 0)

    {

        printk("Cannot encode message!\n");

    }

    err = nfc_t2t_payload_set(ndef_msg_buf, len);

    if (err < 0) {

        printk("Cannot set payload!\n");

    }

}

[AHaug]

Hi Frog,

I have been trying to recreate the error you are describing without any luck since your last reply. If possible. If you can zip and attach a project that does not contain any sensitive information but that has the error I can take a closer look at what the reason might be.

I have asked some of my colleagues about if there exists any more additional information about what resources the NFC code might be competing for. It might take some time before this reply returns due to the current holiday/vacation period in Norway.

Kind regards,
Andreas