[ST25r3916] Switch from LISTENER to POLL

[pagano.paganino]

Hello,

is it possible to switch from LISTENER to POLL mode at runtime and vice versa? I have enabled both POLL and LISTENER at compile time but only the reader mode works.

Any suggestions? can i do it via register?

Thanks and regards

[Ulysses HERNIOSUS · Accepted solution]

Hello pagano.paganino,

our demos in e.g. X-CUBE-NFC6 and STSW-ST25RFAL-002 or in STSW-ST25R016 are time-multiplexing between Poller and Listener. A proper state machine implementing these switches is in rfal_nfc layer.

What is the reader device which should discover the 3916 in card emulation?

I am asking as it may get tricky if both devices (phones) are alternating between Poller and Listener mode. Depending on implementation details on both sides there are situations where you always end up in the same mode.

Best Regards, Ulysses

[pagano.paganino]

Hello Ulysses,

sorry, is not a real problem ...

I have erroneously added

discParam.techs2Find |= RFAL_NFC_LISTEN_TECH_B;

if I remove this all works correctly.

Thanks and best regards

[PablodMM]

Hi fellow ST Developpers,

I am having big trouble with the ST25r3916 regarding using the device to use it with an Android Phone both as a tag emulator and a card reader.

The problem consist in that my program (based on STM32L476RG_NUCLEO_NDEF_BLUETOOTH_PAIRING_NFC6), if searching for both RFAL_NFC_POLL_TYPE_NFCA and RFAL_NFC_LISTEN_TYPE_NFCA, the phone is always detected just as a RFAL_NFC_LISTEN_TYPE_NFCA if

discParam.techs2Find     |= RFAL_NFC_POLL_TECH_A;

is active.

if RFAL_NFC_POLL_TECH_A is not active, the phone can be easily detected as RFAL_NFC_POLL_TYPE_NFCA .

Do you know what the issue may be? I there any way for the SW to let me choose between both?

Thanks!

[Ulysses HERNIOSUS]

Hi Pde M.1,

well you describe it correctly: If you select only one mode then you define the only possible connection.

If you define both then it is open which role gets selected when talking to another device also filling both roles. It can be random, but the chosen timing and other circumstances may heavily bias the outcome.

Regards, Ulysses

[PablodMM]

Thank Ulysses,

Considering I can't control the Android Phone (neither in IOS), would you suggest a cycle sequence of Only Listen and the Only Poll like:

// Only POLL

discParam.techs2Find     |= RFAL_NFC_POLL_TECH_A; // Only POLL

discParam.techs2Find &= not(RFAL_NFC_LISTEN_TECH_A); // Only POLL

osDelay(100); // wait for 100ms

rfalNfcWorker();

action code...

// Only LISTEN

discParam.techs2Find     &= not(RFAL_NFC_POLL_TECH_A); // Only LISTEN

discParam.techs2Find |= RFAL_NFC_LISTEN_TECH_A; // Only LISTEN

osDelay(100); // wait for 100ms

rfalNfcWorker();

action code...

Do you think that could work? Would you have any suggestions as how to manage it?

Kind regards,

Pablo dMM

[Ulysses HERNIOSUS]

Hi Pablo,

Yes, you can issue rfalNfcDeactivate(false) and then start a different discovery.

Existing polling loop is basically just doing that: Acting as a poller for some 50-100ms and then for the rest of the totalDuration switching to listen mode.

Still not clear what you really want o achieve... 50% of time discovered in one mode and 50% in the other mode? This is hard to achieve as different phones are behaving differently.

Best Regards, Ulysses

[PablodMM]

Hi Ulysses,

THe issue I am having is that the ST25 never detects a RFAL_NFC_POLL_TYPE_NFCA, if

discParam.techs2Find     |= RFAL_NFC_POLL_TECH_A;

is active. It is always detected as RFAL_NFC_LISTEN_TYPE_NFCA.

Then, apart from stablishing a higuer values for totalDuration, what other measures can be put to use in the ST25 to bias the outcome?

Best Regards, Pablo dMM

[Ulysses HERNIOSUS]

Hi Pablo dMM,

maybe for clarification as it may confuse a bit:

• techs2Find: RFAL_NFC_POLL_TECH_A means that the ST25R3916 will be acting as Poller in NFC-A and can find devices of type RFAL_NFC_LISTEN_TYPE_NFCA
• techs2Find: RFAL_NFC_LISTEN_TECH_A means that the ST25R3916 will be answer as Listener in NFC-A and can find/be found by devices of type RFAL_NFC_POLL_TECH_A

You could try to analyze the behavior of our software vs the behavior of the specific phone to see why it maybe always ends up in the same mode. Sometimes we have seen one device its polling loop to the other and then always ending up in the same behavior. But changing here something is difficult and may be void with the next mobile.

My advice is that if you need in some use cases one mode and in other use cases other mode then you have to switch this from the application / let the user switch the modes for a longer time.

Best Regards, Ulysses