Skip to main content
ST Migration account
ST Community Manager
August 22, 2026
Solved

HLTA command issue

  • August 22, 2026
  • 11 replies
  • 4 views

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

Best answer by ST Migration account

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

11 replies

ST Migration account
ST Community Manager
August 22, 2026

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

This account posts content from May 22 – Jun 9 that was not included in the community migration.
ST Migration account
ST Community Manager
August 22, 2026

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

This account posts content from May 22 – Jun 9 that was not included in the community migration.
Ulysses HERNIOSUS
ST Technical Moderator
August 22, 2026

Hi,

where there is light, there will be also shadow:

Doing your own firmware gives you control but without testing yourself against NFC Forum will inevitably lead to violations (timings, procedures, error handling) of this standard and possibly inter-operability issues.

BR, Ulysses

Brian TIDAL
ST Technical Moderator
August 22, 2026

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

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.
ST Migration account
ST Community Manager
August 22, 2026

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

This account posts content from May 22 – Jun 9 that was not included in the community migration.
Brian TIDAL
ST Technical Moderator
August 22, 2026

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

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.
ST Migration account
ST Migration accountAuthorBest answer
ST Community Manager
August 22, 2026

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

This account posts content from May 22 – Jun 9 that was not included in the community migration.
Ulysses HERNIOSUS
ST Technical Moderator
August 22, 2026

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

ST Migration account
ST Community Manager
August 22, 2026

Hi, 

you are right.

Fortunately I have to deal only with NFC Forum Type 2 Tag and ISO/IEC14443 Type A specifications., otherwise it would be an enormous hazard and an arduous work.

BR, zanovilla

This account posts content from May 22 – Jun 9 that was not included in the community migration.
ST Migration account
ST Community Manager
August 22, 2026

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

 

This account posts content from May 22 – Jun 9 that was not included in the community migration.
Ulysses HERNIOSUS
ST Technical Moderator
August 22, 2026

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