CR95HF FTM message cut after 63/64 bytes

[LKowa.2]

Hi,

I'm using CR95HF transceiver board for FTM communication with ST25DV64K tag. I've set up python script with ctypes module to use CR95HF.dll.

Everything works fine until I try to write and read longer messages in mailbox. For some strange reason, if i write msg of 105 bytes of data, mailbox length returns correct message length, but if I try to read the same data i get only 126 characters (63 bytes).

I've checked, by reading mailbox in parts, that first 126 characters are valid, but rest of it contains random characters.

I'm working with CR95HF.dll rev. 1.2 and MCU FW 3.7.1, so according to datasheets it should easily cover messages up to 256 bytes of data.

Do You have any idea what can be a root cause here?

I've already tried:

• using SendRecv (0x04) and STCmd (0x01) commands
• changing modulation in protocol settings
• running commands in "extended messages" mode (0x02A8)
• changing buffer size in ctypes's create_string_buffer
• changing WriteMessage (0xAA) to FastWriteMessage(0xCA) - got errors on frame timeout
• using another CR95HF transceiver board
• using another tag
• calling script under linux with CR95HF.so compiled library
• adding delays between commands
• using ST25PC-NFC application for FTM (I suppose it uses the same library)
• running command in addressed mode

[Brian TIDAL]

Hi,

can you explain "i get only 126 characters (63 bytes)." Do you use double byte encoding? I believe the DLL supports C byte-strings and not double bytes strings.

Rgds

BT

[LKowa.2]

Hi,

basicly I'm writing to MB:

0104 6E 02AA02 69 02502E2054656D70736B6900000000000000000000313030373139393000000000000000000000000000000000000000000000000000000000000000003030303534370A00000000000000000000000000000000000000000000000000000000000000000031363134

but when i read mb right after writing above message I get only:

00 02502E2054656D70736B6900000000000000000000313030373139393000000000000000000000000000000000000000000000000000000000

plus 8005 at the beginning and error_code + crc at trail. In total 126 characters.

When I split read command to read only 0x1F of data at a time, then I can see that rest of characters is a random junk:

read_MB_msg_length - Command OK! (means it returned 0069)

read_MB_msg - Command NOK! Expected:010F(ignore that as its placeholder for now) Got:0002502E2054656D70736B6900000000000000000000313030373139393000000000000000000000000000000000000000000000000000000000

read_MB_msg_part - Command NOK! Expected:010F Got:0002502E2054656D70736B69000000000000000000003130303731393930000000

read_MB_msg_part - Command NOK! Expected:010F Got:000000000000000000000000000000000000000000000000000017100008640000

read_MB_msg_part - Command NOK! Expected:010F Got:0000D908000863A60000D34B0008640000000B4C000864000000F9FFFFFF0A0000

Each of read_MB_msg_part reads the next 1F of data.

[Brian TIDAL]

Hi,

8005 means:

• 80: Frame correctly received (additionally see CRC/Parity information)
• 05: five valid bytes in the buffer after this length, including a 2 bytes CRC and a CRC info

So the receive buffer has only 7 valid bytes (8005 + 5 bytes). Other bytes are just the junk from previous use of the buffer.

The command format is described in the ST25R95/CR95HF Datasheet, in particular §5.6 for the sendRecv command. See also AN3954.

I would recommend to use the PC software executable for DEMO-CR95HF-A board to test and debug your commands and then port to your Python environment.

Rgds

BT

[LKowa.2]

Ok,

my bad, I overestimated that its always 8005. When I was starting working on NFC communication I just realized that I don't need these bits of data, so I was trimming them from every cmd reply:

Now here's what I'm getting:

read_MB_msg_length - Command NOK! Expected:002A Got:b'8005002A1F8100'

read_MB_msg - Command NOK! Expected:010F Got:b'802F0000000600000000000000ACF76D3876302E352E300000000000000000000000000000000000000000000000C31700'

write_MB_msg_commit_enrollment - Command NOK! Expected:00 Got:b'80040078F000'

read_MB_msg_length - Command NOK! Expected:0069 Got:b'8005006980F100'

read_MB_msg - Command NOK! Expected:010F Got:b'803D0002502E2054656D70736B6900000000000000000000313030373139393000000000000000000000000000000000000000000000000000000000171000'

read_MB_msg_part - Command NOK! Expected:010F Got:b'80240002502E2054656D70736B69000000000000000000003130303731393930000000B81200'

read_MB_msg_part - Command NOK! Expected:010F Got:b'8024000000000000000000000000000000000000000000000000000017100008640000A73000'

read_MB_msg_part - Command NOK! Expected:010F Got:b'80240000D908000823E60000D34B0008640000000B4C000864000000F9FFFFFF0A0000F33300'

read_MB_msg_part - Command NOK! Expected:010F Got:b'8005010F68EE00'

As You can see, it's actually 802F not 8005.

Anyway, as You suggested using PC app, ST25PC-NFC windows can't really be used as the tag I'm working with goes to low power mode when it doesn't receive any data after several seconds (turns off VCC bit of EH_Dyn register) - that's why I use a sequence of commands in python.

[Brian TIDAL]

Hi,

So ,for the 1st Read Message Length, the CR95HF returns 8005002A1F810 which means that the tag replies 00 2A and therefore the Mailbox contains 2Ah+1 bytes

For the Read Message, the CR95HF returns 802F 00 [2Ah+1 bytes from the MB] C31700' which is inline with the Read Message Length reply

So this means that the mailbox contains 2Bh bytes from the previous action

For the second read, the Read Message Length return 00 69, which means 69h+1 bytes = 106 (and not 105).

So I believe you can then do a Read Message to get the whole mailbox content in one command

Note: the CR95HF cannot read the full 256 bytes of the mailbox in a single command (the maximum received payload data in SendReceive command is 255-3 (i.e. minus 2 bytes of CRC and 1 byte of CRC info).

Regarding your comment about low power, I believe that the tag device will stay ON as long as the field is ON and the field stays ON until a protocolSelect(Field Off) command is sent to the CR95HF. So even when not sending data, once the field has been put ON, it stays ON until an explicit field off command.

Rgds

BT

[LKowa.2]

Hi,

"So I believe you can then do a Read Message to get the whole mailbox content in one command"

No, I can't. I'm trying to do that in line:

read_MB_msg - Command NOK! Expected:010F Got:b'803D0002502E2054656D70736B6900000000000000000000313030373139393000000000000000000000000000000000000000000000000000000000171000'

I receive only 3Ch + 1 bytes of data from MB while I sent 69h bytes:

0104 6E 02AA02 69 02502E2054656D70736B6900000000000000000000313030373139393000000000000000000000000000000000000000000000000000000000000000003030303534370A00000000000000000000000000000000000000000000000000000000000000000031363134

It really seems like I can send to mailbox only 3Ch bytes of correct data while the rest: 69h - 3Ch = 2D(more or less) is filled with probably random junk.

I suspect, that from write command it knows, that 69h bytes of data should be put in mailbox, but can transfer only 3Ch bytes of it.

So to summarize:

I write to MB:

0104 6E 02AA02 69 02502E2054656D70736B6900000000000000000000313030373139393000000000000000000000000000000000000000000000000000000000000000003030303534370A00000000000000000000000000000000000000000000000000000000000000000031363134

MB length command returns 69h

Read ALL from MB returns:

803D0002502E2054656D70736B6900000000000000000000313030373139393000000000000000000000000000000000000000000000000000000000171000

Read MB from address 00h to 1Fh:

80240002502E2054656D70736B69000000000000000000003130303731393930000000B81200

Read MB from address 20h to 3Fh:

8024000000000000000000000000000000000000000000000000000017100008640000A73000

Read MB from address 40h to 5Fh:

80240000D908000823E60000D34B0008640000000B4C000864000000F9FFFFFF0A0000F33300

Read MB from address 60h to 7Fh:

8005010F68EE00

From first glance You can see that while reading MB in parts allow me to get to whole message, but it's corrupted.

What should be:

02502E2054656D70736B6900000000000000000000313030373139393000000000000000000000000000000000000000000000000000000000000000003030303534370A00000000000000000000000000000000000000000000000000000000000000000031363134

What is (when I concatenate these 3 strings above - 4th doesn't contain anymore data):

02502E2054656D70736B69000000000000000000003130303731393930000000000000000000000000000000000000000000000000000000001710000864000000D908000823E60000D34B0008640000000B4C000864000000F9FFFFFF0A0000

For now I'm out of ideas what might be a problem here. I've found 2 other topics regarding similar issue, but both of them didn't conclude with a clear solution.

[Brian TIDAL]

Hi,

can you provide a dump of the various commands send and the responses received from the CR95HF including the initialisation phase (CR95HF protocolSelect and CR95HF register writes if any)?

Rgds

BT

[LKowa.2]

Sure,

dump from commands used in sequence:

present_password - Command NOK! Expected:00 Got:b'80040078F000'

set_dynamic_gpo - Command NOK! Expected:00 Got:b'80040078F000'

set_MB_MODE - Command NOK! Expected:00 Got:b'80040078F000'

set_MB_CTRL_Dyn - Command NOK! Expected:00 Got:b'80040078F000'

set_dynamic_gpo - Command NOK! Expected:00 Got:b'80040078F000'

write_MB_msg - Command NOK! Expected:00 Got:b'80040078F000'

reset_dynamic_gpo - Command NOK! Expected:00 Got:b'80040078F000'

set_dynamic_gpo - Command NOK! Expected:00 Got:b'80040078F000'

read_MB_msg_length - Command NOK! Expected:002A Got:b'8005002A1F8100'

read_MB_msg - Command NOK! Expected:010F Got:b'802F00000006000000000000002C946E3876302E352E3000000000000000000000000000000000000000000000007A5F00'

reset_dynamic_gpo - Command NOK! Expected:00 Got:b'80040078F000'

set_dynamic_gpo - Command NOK! Expected:00 Got:b'80040078F000'

write_MB_msg_commit_enrollment - Command NOK! Expected:00 Got:b'80040078F000'

read_MB_msg_length - Command NOK! Expected:0069 Got:b'8005006980F100'

read_MB_msg - Command NOK! Expected:010F Got:b'803D0002502E2054656D70736B6900000000000000000000313030373139393000000000000000000000000000000000000000000000000000000000171000'

read_MB_msg_part - Command NOK! Expected:010F Got:b'80240002502E2054656D70736B69000000000000000000003130303731393930000000B81200'

read_MB_msg_part - Command NOK! Expected:010F Got:b'8024000000000000000000000000000000000000000000000000000017100008640000A73000'

read_MB_msg_part - Command NOK! Expected:010F Got:b'80240000D908000863A60000D34B0008640000000B4C000864000000F9FFFFFF3A00001B4100'

read_MB_msg_part - Command NOK! Expected:010F Got:b'8005010F68EE00'

read_MB_msg_part - Command NOK! Expected:010F Got:b'8005010F68EE00'

read_MB_msg_part - Command NOK! Expected:010F Got:b'8005010F68EE00'

read_MB_msg_part - Command NOK! Expected:010F Got:b'8005010F68EE00'

reset_dynamic_gpo - Command NOK! Expected:00 Got:b'80040078F000'

set_dynamic_gpo - Command NOK! Expected:00 Got:b'80040078F000'

read_MB_msg_length - Command NOK! Expected:002A Got:b'80050002552C00'

read_MB_msg - Command NOK! Expected:010F Got:b'800700020105130700'

reset_FTM - Command NOK! Expected:00 Got:b'80040078F000'

Function name - command used

present password - 01040C02B302000000000000000000

set_dynamic_gpo - 01040402A90200

reset_dynamic_gpo - 01040402A90201

set_MB_MODE - 01040502A1020D01

set_MB_CTRL_Dyn - 01040502AE020D01

write_MB_msg - 01040502AA020000

read_MB_msg_length - 01040302AB02

read_MB_msg - 01040502AC020000

read_MB_msg_part(pointer, length) - 01040502AC02 + pointer + length

write_MB_msg_commit_enrollment is the same as write_MB_msg, but has hardcoded command length(values in bold)

[Brian TIDAL]

Hi,

the first Write Message is erroneous: the Message Data payload should have (MSGLength + 1) bytes  i.e. 6Ah bytes but only has 69 bytes. Can you check?

As suggested in my previous posts, can you try to test your commands with the  PC software executable for DEMO-CR95HF-A board and send me the log?

Can you share the content of the protocol Select command (in particular 10% vs. 100%)?

Can you try to read the message with its explicit length rather that 0 (i.e. with the length returned by the Read Message Length command)?

Is there an application running on I2C side that modify the content of the mailbox or change the register settings of the ST25DV?

Rgds

BT

[Brian TIDAL]

Hi

I believe I've reproduced your issue with the  PC software executable for DEMO-CR95HF-A board. This needs further investigation but likely an issue with the CR95HF.DLL.

I'll keep you posted.

Rgds

BT