CR95HF cannot receive more than 64 bytes with iso14443 type select

messa.1 · ‎2020-09-29

Hello all,

I have an issue with CR95HF chip that it cannot return more than 62 data bytes (after deducting control and CRC bytes ) . The FiFo buffer should contain about 256 bytes.

I am using STM8 and i have my own implementation .

The issue happens with me while sending Read binary APDU command with 255 bytes length

when i read the received data from chip i found that there is 62 bytes only .

Thanks alot in Advance

Brian TIDAL · ‎2020-09-29

Hi,

as explained in the previous post, I recommend E0 70 (i.e. up to 128 bytes).

I would suggest to check in the tag datasheet the maximum read size and align the read binary APDU request accordingly.

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.

View solution in original post

Brian TIDAL · ‎2020-09-29

Hi,

I suspect that the issue is due to the FSDI parameter in the RATS sent in your implementation. The FDSI codes the FSD. The FSD defines the maximum size of a frame the reader is able to receive. My guess is that you send RATS = E0 50 i.e. FSDI=5 (64 bytes) and CID=0.

I would suggest to use FSDI=7 (128 bytes). As the <Len> parameter of the response from the CR95HF to the host is one byte, it is not possible to receive 256 bytes.

Also, NFC Type 4 tags have a MLe parameter in the CC file that specifies the Maximum number of bytes that can be read. Which tag do you use?

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.

messa.1 · ‎2020-09-29

Hi,

Thanks alot for you reply.

Yes you are right when i adapt RATS commands to be E0 80 currently i can receive 255 bytes

but now there is unstable behavior that some time i request to read 200 bytes and receive 60 bytes and while i am repeating the read binary APDU , i receive different numbers ( 10 bytes , 64 bytes , 20 bytes and 130 bytes) .

Iam using 32k smart card based on infenion chip

Brian TIDAL · ‎2020-09-29

Hi,

as explained in the previous post, I recommend E0 70 (i.e. up to 128 bytes).

I would suggest to check in the tag datasheet the maximum read size and align the read binary APDU request accordingly.

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.

messa.1 · ‎2020-09-29

Hi,

Actually i have checked the datasheet of the card and i found that is supports up to 255 bytes

but what about unstable behavior of receiving data

Brian TIDAL · ‎2020-09-29

Hi,

the CR95HF returns what it has received from the tag, so if what you received is segmented, well, the issue is likely on tag side.

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.