Problem using listen mode on the st25r3916b

[JBark.3]

I am trying to use the st25r3916b in listen mode to act as an NFCA card.

After successful calls to rfalNfcInitialize() and rfalListenStart(RFAL_LM_MASK_NFCA, ...) I am entering into a loop and calling rfalWorker(). In the same loop I call rfalListenGetState to try and see if any data comes back from the reader, which never does.

After debugging this some, I can see that inside rfalRunListenModeWorker (called from rfalWorker) always goes through the following state change:

RFAL_LM_STATE_POWER_OFF ->

RFAL_LM_STATE_IDLE ->

RFAL_LM_STATE_POWER_OFF

This seems to be happening because ST25R3916_IRQ_MASK_EOF is set on the st25r3916b's register. This feels strange because ST25R3916_IRQ_MASK_EON is also set, which is required for it to leave the idle state in the first place.

I feel like the chip is not configured properly, but I have no idea why.

Notes about setup:

X-NUCLEO-NFC08A1 dev board connected to NUCEL F401RE dev board.

I have successfully tested the setup in polling mode and can read cards no problem.

[Ulysses HERNIOSUS]

Hi,

what is the counter part you are using? A phone? Better to start off with another st25r39... reader and executing field-on, Send a request, etc. driven by a GUI.

Reason is that phones are doing wake-up and very fast polling and depending on the timing of your port you may miss to go into the right states fast enough.

Having I_eon and I_eof together is often an effect of a phone performing short (few us) pulses to detect a detuning in its tank (wake-up aka LPCD).

As reference please also get NUCLEO-L476 and run the stop demos from ST25 embedded NFC lib which contains a ready working card emulation demo (pairing).

Best Regards, Ulysses

[JBark.3]

Thanks for the info.

I had been suspicious of the timing so I am not surprised to hear this suggestion. I noticed that my app has more success when I turn off usart logging so I am guessing that my paranoid debugging logs might be causing some issues, this will make this quite hard to investigate if I cannot use logs or breakpoints. I wonder if I need to maintain an in memory log and then dump to usart at a less time sensitive moment.

[JBark.3]

@Ulysses HERNIOSUS_O​ this is all working now, mostly!

Everything is working and my emulated card is picked up by the reader device with all the right data.

I am now seeing an issue where my firmware locks up after an amount of time. It's sometimes after a couple of scans, sometimes right away.

Debugging this I can see that my code gets stuck here st25r3916CheckForReceivedInterrupts, it's stuck in here while( platformGpioIsHigh( ST25R_INT_PORT, ST25R_INT_PIN ) ) because the interrupt pin never goes low.

I am not sure how to debug this further since this is the st25r3916b keeping the pin high.

[Ulysses HERNIOSUS]

Hi,

the st25r3916CheckForReceivedInterrupts() is issuing calls to read the interrupt status register of the st25r3916. Is this read correctly executed? What is the register content it is reading?

Regards, Ulysses