HLTA command issue

[zanovilla]

Hello, i need help for an issue with HLTA command.

I'm working with ST25R100 and I'm writing code direclty in uP without RFAL library. 

I finished writing anticollision routine and it works fine, but when I try to put PICC in HALT mode it continues to respond to REQA command.

Because PICC comes from SELECT command, I think that registers settings are ok for HLTA command and I need to do no change about them. I take care not to turn off RF field so selected PICC does not return to IDLE state....

Also, if I send a READ command to PICC instead of HLTA I can read all data without any problem.

Any suggestion? 

Thank you

[Brian TIDAL]

Hi,

could you connect a logic analyzer on SPI (CLK, MOSI, MISO, CS) and IRQ_ST25R100 and send us the raw log file?

It is recommended to use the RFAL. It is scalable and portable on different MCU. It has been tested against various NFC and ISO test suites. Just for my curiosity, what are the reasons for not using it?

Rgds

BT

[zanovilla]

Only for optimized code reason.

Here are transactions with one PICC only in RF field until HLTA command. Do you note something wrong?

Thank you

[Brian TIDAL]

Hi,

could you send the raw log file (not CSV) i.e. .dvdat if digiview or .sal if salae etc. including the command sent after the SLP_REQ (50 00) i.e. when the tag replies to the second REQA? 

Could you also confirm that this is a Type 2 tag from NxP? Could you provide information on the tag model (Mifare UL etc.)?

Regarding the RFAL, it is fully scalable: features you don't need can be disabled through compilation switches and the code size is reduced accordingly. It provides a high layer performing the overall NFC activities as well as individual low layer API that can be used by advance users who need more control. Moreover, the RFAL sets the various analog registers for proper RF communication. These are the reasons to recommend using the RFAL.

Rgds

BT

[zanovilla · Accepted solution]

Hello, 

problem is solved: I had not noticed that bit5 of OPERATION REGISTER turn off RF field if it is disabled...and so PICC go in IDLE state answering to REQA command that follows.

Now just a question:

why in IRQ mask register 1 bit M_subc_start is masked in default state ?

why in IRQ status register 1 bit I_subc_start is ON in default state ?

Thank you

[Ulysses HERNIOSUS]

Hi zanovilla,

not sure what you mean: ST25R100 startup state of M_subc_start should be 0. RFAL by default puts it to 1 (IRQ masked). 

Please describe what you are doing! With/without RFAL?

Ulysses

[zanovilla]

Hello, 

I'm looking at SR25R100 datasheet about registers default values. So RFAL reiterates defaul value for M_subc_start. But what about I_subc_start default value? Is it a typo?

I'm working without RFAL

[Ulysses HERNIOSUS]

Hi,

I am inclined to say these are typos. But we are in the course of analyzing. 

subc_start is more of an informational interrupt - I expect no major impact on your software and its operation, right?

BR, Ulysses

[Grégoire Poulain]

Hi,

Thanks for you observations and reporting.

Indeed there is a typo on the DS in regards to I_subc_start bite - its default value should read 0 (not 1).
It will be amended in an upcoming revision of the Datasheet.


Concerning the masking of the IRQ, the motivation is that this bit is not commonly used/handled as an interrupt, but rather a "status bit" that can be checked at the end of the transceive operation (as in RFAL).
In typical use cases there is no need to handle the I_subc_start event directly nor trigger any specific handling of by the MCU, is merely informative.

Hope it clarifies.

Kind regards
GP

[zanovilla]

Hi, 

thanks for your replies. Now all seems to work, but if I'll need other explanations I know that I can write here!

Working without RFAL gives me the opportunity to fully investigate chip operation having full firmware control.

We use to work in this way.

Regards