cancel
Showing results for 
Search instead for 
Did you mean: 

I'm using rfal lib 1.3.0 on ST25r3916 on NUCLEO-NFC05A1. nfc_demo_poller gets stuck randomly sometimes and my embedded platform is completely unavailable. How this can be solved?

SParr.1
Associate II

I have developed an embedded Linux board (microprocessor ARM Cortex-A5 core) which is connected through SPI port to a NUCLEO-NFC05A1. I want to detect tags and then transmit the interrupt event (aka the tag present) to the main board, on which the rfal lib (v.1.3.0) is running.

Actually, everything works fine and tags are detected most of the times. Anyway, sometimes (I don't know why, it does not seem to be related to anything else), the nfc-poller demo stucks and drags all the board resources together (the maximum priority thread does not allow to make any other operation). I've tried to run the nfc-poller demo alone and it stucks itself (randomly) even if it is left to run without tags to be detected. To resume, nfc-poller demo works, but it has this bad feature of blocking itself and also blocking the main board. Adding watchdogs seem to be not so effective, because it is nearly impossible to know and detect where the software is stuck.

Thank you

1 ACCEPTED SOLUTION

Accepted Solutions
SParr.1
Associate II

Dear Ulysses,

I've tried version 2.2.0 for ST25r3911 just now. It seems much more reliable. Maybe many issues like unexpected behaviors have been solved ...

I've been running the provided demo nfc_poller for more than 10 minutes and it has not stopped ... Let's hope it's the solution!

Regards,

S.

View solution in original post

7 REPLIES 7
Ulysses HERNIOSUS
ST Employee

Hi SParr.1,

hard to judge from the information you provided. Would need to know either the sequence of functions executed in your nfc thread or best to have also an SPI trace which will also help a lot (SPI+IRQ).

Best Regards, Ulysses

SParr.1
Associate II

Hi Ulysses,

thank you for your quick reply.

Actually, I'm just using the "ST25R3911B NFC Poller Demo on Linux" provided by ST in version rfal 1.3.0 with no alterations... It works (it correctly detects one or more TAG when shown, for example), but I was noticing that if I leave the for(;;) in exampleRfalPoller.c to run endlessly, it stucks at a certain point and this is not deterministic...

Regads,

S.

Ulysses HERNIOSUS
ST Employee

Hi SParr.1,

Do you mean that you cannot even send <BREAK>/Ctrl-C to end the process? If that is the case then I would suspect an hardware issue.

Besides some ideas to identify hangs within the NFC demo:

  1. Are there still interrupts being signaled in IRQ thread? You could put a breakpoint there.
  2. What is the state of the Interrupt pin when it hangs? Constant high?
  3. As mentioned before it would be good to get traces using a logic analyzer (SPI+IRQ) when the issue happens. Some Logic Analyzer support free-running, just try to capture what happens when it started the hang.

Best Regards, Ulysses

SParr.1
Associate II

Hi Ulysses,

here are the answers:

1) "Do you mean that you cannot even send <BREAK>/Ctrl-C to end the process?"  - yes, that's what happens.

2) "Are there still interrupts being signaled in IRQ thread? You could put a breakpoint there." - ok, that would be interesting to know. I suspect exactly that something is running while some thread is conversely dead

3) "What is the state of the Interrupt pin when it hangs? Constant high?" - that's another interesting point. A notation is the following: for some blocking events, if I remove the IRQ wire and then put back, the demo re-starts to run

4) "As mentioned before it would be good to get traces using a logic analyzer (SPI+IRQ) when the issue happens. Some Logic Analyzer support free-running, just try to capture what happens when it started the hang." - I think it's a process to long to take for my development, considering I have not any OS interface on my embedded board...

Thank you,

S.

SParr.1
Associate II

Dear Ulysses,

I've tried version 2.2.0 for ST25r3911 just now. It seems much more reliable. Maybe many issues like unexpected behaviors have been solved ...

I've been running the provided demo nfc_poller for more than 10 minutes and it has not stopped ... Let's hope it's the solution!

Regards,

S.

Hi SParr.1,

Glad to hear that updating resolved the issues.

For our knowledge and to potentially improve our deliveries: Did you update using only RFAL coming from STSW-RFAL001 or did you combine actually with STSW-ST25R013 (which contains RFAL v2.2.0 for ST25R3916 and also updated glue layer (interrupt thread, etc))?

Regards, Ulysses

SParr.1
Associate II

Dear Ulysses,

I've started from rfal library + linux_demo provided code (I think the package, wherever is included in other bigger packages, is denoted as Linux_RFAL_st25r39xx_v2.2.0). Then, I've adapted the demo code and glued to my main routines.

I think that providing the lib + at least one example of use is the best...

Regards,

S.