2021-03-09 05:57 AM
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
Solved! Go to Solution.
2021-03-09 08:49 AM
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.
2021-03-09 06:58 AM
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
2021-03-09 07:35 AM
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.
2021-03-09 08:03 AM
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:
Best Regards, Ulysses
2021-03-09 08:41 AM
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.
2021-03-09 08:49 AM
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.
2021-03-11 03:03 AM
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
2021-03-11 03:21 AM
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.