cancel
Showing results for 
Search instead for 
Did you mean: 

How to handle SLP_REQ (HLTA) command in listen mode using st25r3916b

JBark.3
Associate II

Hi. I am using the st25r3916b to emulate an nfca card. This working most of the time, different readers are able to read the emulated card and the exchange behaves as expected.

Sometimes the reader device sends the SLP_REQ command but I am not sure how to handle this. I try calling rfalListenSleepStart in response, but that returns a LINK_LOSS error.

Not sure if I am doing something wrong.

1 ACCEPTED SOLUTION

Accepted Solutions
Grégoire Poulain
ST Employee

Hi,

The main reason reason why T2T emulation is not recommended nor provided on the lib is the stringent timings requirements.

In order to comply with T2T requirements an answer needs to be provided for example within 4.75ms for a READ and 0.95ms for a SECTOR SELECT.

In CE mode all traffic needs to be sent and handled by the host via SPI/I2C, and back again.

I believe that for the same reason (timing constraints) you are observing the LINK_LOSS error.

By the time the host executes rfalListenSleepStart (which is correct API), the reader already timed out and turned its field Off.

Kind regards

GP

View solution in original post

5 REPLIES 5
Brian TIDAL
ST Employee

Hi,

do you emulate a T2T or T4AT tag? Do you use your own implementation of the Card Emulation or the framework provided by ST?

If you are using a T4AT Card Emulation, once the tag is activated, the reader is not supposed to send a SLP_REQ but a DESELECT. When a Deselect is received, an RFAL_ERR_SLEEP_REQ is returned to the RFAL HL that moves the Card Emulation to Sleep. Can you eleborate on your use case : when is such a SLP_REQ being received? Feel free to provide a logic analyzer trace (SPI + IRQ)

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

I am emulating a type 2 tag, it is an NTAG 215 card.

I am handing the emulation myself because I couldn't see anything in the lib that would handle NTAG 215 or mifare ultralight.

Grégoire Poulain
ST Employee

Hi,

The main reason reason why T2T emulation is not recommended nor provided on the lib is the stringent timings requirements.

In order to comply with T2T requirements an answer needs to be provided for example within 4.75ms for a READ and 0.95ms for a SECTOR SELECT.

In CE mode all traffic needs to be sent and handled by the host via SPI/I2C, and back again.

I believe that for the same reason (timing constraints) you are observing the LINK_LOSS error.

By the time the host executes rfalListenSleepStart (which is correct API), the reader already timed out and turned its field Off.

Kind regards

GP

Thanks for the explanation, that makes sense.

I guess my MCU is just not fast enough to do the round trip in time (recieve the command, detect it as SLP_REQ, then call rfalListenSleepStart). I'll see if I can cut out any unnecessary cycles, but I don't think there is much to gain.

What's the consequence of not being able to call rfalListenSleepStart successfully? I guess I am not even sure why the reader sends SLP_REQ, is that because it is the end of the transaction?

Brian TIDAL
ST Employee

Hi,

can you describe in more details your application (maybe in a private message) and the typical flow between the reader and the card emulation? Do you dynamically change the content of the card emulation memory?

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.