2021-03-04 08:15 AM
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:
Solved! Go to Solution.
2021-03-09 06:31 AM
Hi,
I would recommend to have a look on AN4913 (Energy harvesting delivery impact on ST25DVxxx behavior during RF communication). I would also suggest to debug the communication sequence with the ST25DV being externally powered (stable supply).
Rgds
BT
2021-03-09 07:12 AM
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.
2021-03-09 07:50 AM
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
2021-03-09 12:26 PM
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'
2021-03-12 06:50 AM
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?
2021-03-15 05:38 AM
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
2021-03-15 08:26 AM
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?
2021-03-15 10:07 AM
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
2021-03-15 10:50 AM
Hi,
I'm using CR95HFDll_SendReceive function. Please provide source code for the library. I have to make it work under windows and linux.
2021-03-18 03:34 AM
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