ST25R3918: Unstable efd_o bit in Auxiliary Display Register after NFC-F Card Emulation response

[Tyama.1]

Hello,

I am using the ST25R3918 controlled by an MCU via RFAL, operating in NFC-F / FeliCa card emulation mode.

I am monitoring the efd_o bit (bit 6) of the Auxiliary Display Register (Address: 31h) to detect when the board approaches an external reader. While I observe that efd_o stays at '1' during the initial idle state and during the first few commands, it becomes unstable (toggling between 0 and 1) after the communication sequence is completed.

Sequence of operations:

1. Receive Write Without Encryption from the reader.
2. Send response for Write Without Encryption.
3. Receive Read Without Encryption.
4. Send response for Read Without Encryption.
5. Reader terminates the communication.
6. efd_o becomes unstable (toggling 0/1) for several hundred milliseconds. (Note: efd_o is stable at '1' during steps 1 through 4.)

RFAL Configuration:

• discParam.devLimit = 1U;
• discParam.totalDuration = 60000U;
• discParam.techs2Find = RFAL_NFC_LISTEN_TECH_F;

Questions:

1. Is this unstable behavior of efd_o expected after a transaction in NFC-F Card Emulation?
2. Could this be caused by an incorrect state transition in RFAL or a specific register setting required after a response is sent?
3. Should I be clearing any specific interrupts or re-initializing the field detector after the communication ends?

Any insights would be greatly appreciated. Thank you!

[Brian TIDAL]

Hi,

at the end of the communication, the external reader likely implements a kind of removal check procedure (toggle field on - off - on and then check whether the same device is still in the operating volume and repeat this sequence). This can be verified by probing the field from the external reader with a scope (connect the gnd of the probe to the tip of the probe and put the probe in the field: this should capture the field).

Rgds

BT

[Tyama.1]

Hello,

Thank you very much for your explanation regarding the external reader behavior.

Based on your suggestion, we will also try to capture the external reader field using a scope in order to verify the field on–off–on behavior during and after communication.

Your description of the removal check procedure (toggling the field on–off–on to verify whether the same device remains in the operating volume) was very helpful and clarified our observation.

As a follow-up question, I would like to ask whether this kind of removal check procedure is generally used in NFC readers.

Specifically, is this on–off–on field toggling sequence a common or recommended practice in typical NFC reader implementations (for example, in commercial or industrial readers), or is it more dependent on the individual reader design or vendor-specific implementation?

Understanding whether this behavior is generally expected would help us determine how robust our field detection and state handling should be during and after communication.

Thank you again for your support.

Best regards,

[Brian TIDAL]

Hi,

A removal procedure is often used to ensure that the user removes the tag from the operating volume before starting the next operation. This prevents executing the same operation multiple times on the same tag. Some NFC Forum applications, such as wireless charging, require a removal procedure; however, the implementation of this procedure is the responsibility of the application developer. Payment applications also require a removal procedure: typically, removal is detected after three WUPA commands with no response for ISO14443-A. Mobile phone readers also implement vendor-specific removal procedures.

Rgds

BT