Visitor II

Solved

CR95HF FTM message cut after 63/64 bytes

Forum|Forum|4 years ago
March 4, 2021
29 replies
4072 views

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

This topic has been closed for replies.

Best answer by Brian TIDAL

After further analysis done by LKowa.2, a preliminary call to CR95HFDLL_getMCUrev() is needed prior to calls to CR95HFDll_SendReceive requiring fragmentation/defragmentation This is due to CR95HFDll_SendReceive() doing an internal check of the MCURev variable before using this fragmentation feature.

Thanks to LKowa.2

BT

Show previous replies

L

LKowa.2Author

Visitor II

Hi,

For now I was able to get a sequence of steps which allow me to write full cmd to MB:

03-09-2021 15:41:31	ANTICOLLISION
			>>> CR95HFDLL_STCMD, 02A00126
			<<< 800A010061FD4250002702E0
03-09-2021 15:41:31	RESET TO READY
			>>> CR95HFDLL_SENDRECEIVE, 0226
			<<< 80040078F000
03-09-2021 15:41:33	PRESENT PASSWORD
			>>> CR95HFDLL_SENDRECEIVE, 02B302000000000000000000
			<<< 80040078F000
03-09-2021 15:41:35	READ DYNAMIC CONFIGURATION (EH_CTRL_Dyn @0x02)
			>>> CR95HFDLL_SENDRECEIVE, 02AD0202
			<<< 80050004634900
03-09-2021 15:41:36	MANAGE GPO (Set GPO)
			>>> CR95HFDLL_SENDRECEIVE, 02A90200
			<<< 80040078F000
03-09-2021 15:41:37	READ DYNAMIC CONFIGURATION (EH_CTRL_Dyn @0x02)
			>>> CR95HFDLL_SENDRECEIVE, 02AD0202
			<<< 8005000C2BC500
03-09-2021 15:41:40	READ DYNAMIC CONFIGURATION (MB_CTRL_Dyn @0x0D)
			>>> CR95HFDLL_SENDRECEIVE, 02AD020D
			<<< 80050000470F00
03-09-2021 15:41:46	WRITE DYNAMIC CONFIGURATION (MB_CTRL_Dyn @0x0D)
			>>> CR95HFDLL_SENDRECEIVE, 02AE020D01
			<<< 80040078F000
03-09-2021 15:41:48	READ DYNAMIC CONFIGURATION (MB_CTRL_Dyn @0x0D)
			>>> CR95HFDLL_SENDRECEIVE, 02AD020D
			<<< 80050001CE1E00
03-09-2021 15:41:49	READ MESSAGE LENGTH (MB_LEN_Dyn)
			>>> CR95HFDLL_SENDRECEIVE, 02AB02
			<<< 80050000470F00
03-09-2021 15:41:50	READ MESSAGE (MB_Dyn Bytes)
			>>> CR95HFDLL_SENDRECEIVE, 02AC020000
			<<< 8005010F68EE00
03-09-2021 15:41:54	WRITE MESSAGE (MB_Dyn Bytes)
			>>> CR95HFDLL_SENDRECEIVE, 02AA0268000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
			<<< 80040078F000
03-09-2021 15:41:57	READ MESSAGE LENGTH (MB_LEN_Dyn)
			>>> CR95HFDLL_SENDRECEIVE, 02AB02
			<<< 8005006809E000
03-09-2021 15:41:59	READ MESSAGE (MB_Dyn Bytes)
			>>> CR95HFDLL_SENDRECEIVE, 02AC020000
			<<< 806D00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000B96700

I tried the same with my script and DLL:

select_ISO15693()
print("anti:"+send_raw("02A00126")) #anticollision
time.sleep(0.1)
print(send_data("0226")) #reset to rdy
time.sleep(0.1)
present_password()
time.sleep(0.1)
print(send_data("02AD0202")) #READ DYNAMIC CONFIGURATION (EH_CTRL_Dyn @0x02)
time.sleep(0.1)
print(send_data("02A90200")) #MANAGE GPO (Set GPO)
time.sleep(0.1)
print(send_data("02AD0202")) #READ DYNAMIC CONFIGURATION (EH_CTRL_Dyn @0x02)
time.sleep(0.1)
print(send_data("02AD020D")) #READ DYNAMIC CONFIGURATION (MB_CTRL_Dyn @0x0D)
time.sleep(0.1)
print(send_data("02AE020D01")) #WRITE DYNAMIC CONFIGURATION (MB_CTRL_Dyn @0x0D)
time.sleep(0.1)
print(send_data("02AD020D")) #READ DYNAMIC CONFIGURATION (MB_CTRL_Dyn @0x0D)
time.sleep(0.1)
print(send_data("02AB02")) #READ MESSAGE LENGTH (MB_LEN_Dyn)
time.sleep(0.1)
print(send_data("02AC020000")) #READ MESSAGE (MB_Dyn Bytes)
time.sleep(0.1)
print(send_data("02AA0268000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000")) #WRITE MESSAGE (MB_Dyn Bytes)
time.sleep(0.1)
print(send_data("02AB02")) #READ MESSAGE LENGTH (MB_LEN_Dyn)
time.sleep(0.1)
print(send_data("02AC020000")) #READ MESSAGE (MB_Dyn Bytes)

This is the result:

anti:b'800A010061FD4250002702E0'
b'80040078F000'
present_password - Command NOK! Expected:00 Got:b'80040078F000'
b'8005000C2BC500'
b'80040078F000'
b'8005000C2BC500'
b'80050085E2DC00'
b'80040078F000'
b'80050085E2DC00'
b'8005006809E000'
b'803D000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
b'8005010F68EE00'
b'8005006809E000'
b'803D000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'

I'll look deeper into AN4913, but I don't use EH at all. My tag is powered from the device, that it's working in.

B

Brian TIDAL

Technical Moderator

Hi,

can you elaborate on your power saving management and in particular the Vcc management ?

can you double check the DLL revision when running from your python environment to make sure that an old CR95HFDLL is not used ?

Rgds

BT

L

LKowa.2Author

Visitor II

Hi,

sadly, I cannot tell any details about power management. It was not developed by me, and all I know is that if the device is not using NFC communication, then it switches VCC OFF. When this happens I have to remove device from the transceiver's RF field for a moment before trying again.

I triple checked dll rev:

_nfc.CR95HFDll_GetDLLrev(r)
print(repr(r.value))

b'1.2'

L

LKowa.2Author

Visitor II

Hi,

I've eliminated python's ctypes from the root cause list. By compiling this library under linux(the one for which source code is available) and running it in C++ code I was able to reproduce the same issue. How can I verify if windows app is using the same DLL? Maybe it does something differently?

Maybe transceiver board STM firmware have a bug and doesn't slice/concatenate messages correctly?

Is it possible to get older STM firmware revisions?

B

Brian TIDAL

Technical Moderator

Hi,

I confirm that the PC software executable for DEMO-CR95HF-A board uses the CR95HF.dll.

You can use Process Explorer to see DLL info:

The PC software executable for DEMO-CR95HF-A board runs the CR95HF DLL from C:\Windows\SysWOW64

The PC software executable for DEMO-CR95HF-A board communicates thanks to the CR95HF DLL with the transceiver board through HID USB using 64 bytes frames. As this is working with PC software, we can conclude that the transceiver board firmware is able to properly slice and concatenate the 64 bytes USB frames.

Can you install Process Explorer and check the DLL being used in your environment?

Rgds

BT

L

LKowa.2Author

Visitor II

Hi,

I can confirm that my PC software uses the same DLL - the one from C:\Windows\SysWOW64.

I did compare this ddl with dll in my python project - the are the same, same size and creation date. Only modification date is different (dll from SysWOW is from Dec 2017), but even after replacing this dll I have the same issue.

How can we be sure that slicing and concatenating messages is being done by a DLL, and not by PC software itself?

I've tried to find slicing/concatenating functions in CR95HF C++ Library for Linux User https://www.st.com/en/embedded-software/stsw-95hf004.html

without success. Could You point me to it?

B

Brian TIDAL

Technical Moderator

Hi,

the frame fragmentation/defragmentation is done inside the Windows DLL but only for the CR95HFDll_SendReceive API. If you use CR95HFDll_STCmd API + 04, it will not be fragmented/defragmented. Make sure to use CR95HFDll_SendReceive rather than CR95HFDll_STCmd.

The Linux version is older than the support of fragmentation/defragmentation and therefore does not support this fragmentation feature. If you need this feature on Linux, we can provide to you in private the latest source code of the Windows version so that you can backport the updated CR95HFDll_SendReceive version in the Linux library.

Rgds

BT

L

LKowa.2Author

Visitor II

Hi,

I'm using CR95HFDll_SendReceive function. Please provide source code for the library. I have to make it work under windows and linux.

B

Brian TIDALAnswer

Technical Moderator

After further analysis done by LKowa.2, a preliminary call to CR95HFDLL_getMCUrev() is needed prior to calls to CR95HFDll_SendReceive requiring fragmentation/defragmentation This is due to CR95HFDll_SendReceive() doing an internal check of the MCURev variable before using this fragmentation feature.

Thanks to LKowa.2

BT

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded