Can I have some guidance on how to use the STR25R3111DISCOComm DLL for ISO 15693 R2H FTM transfers in C++?

[tim239955_stm1_stmicro_com]

I am trying to develop an application in C/C++ (QT) to perform an ISO 15693 R2H FTM data transfer with an STDV04 tag using the STR25R3111DISCOComm DLL. I am able to link to the DLL, connect to the DISCO board and perform a passive read on my tag using my own code. I have also been able to perform successful FTM transfers using the ST Tag Editor. But it is not at all clear how I perform those transfers in my code using the DLL.

Below is the log from ST25DV FTM Demo of the type of transfer I wish to perform. How do I reproduce that with DLL calls?

I tried using iso15693TxRxNBytes() to send the data that is being logged as sent by the ST25R3911B_SENDRECEIVE commands, but when I get to sending command 0xAA, I always get an INVALID_CRC error back.

Reading other posts, I think I need to use the rfalStartTransceive() / rfalGetTransceiveStatus() commands, but I cannot workout what I need to actually send. They always just return data that suggests that I am sending the wrong thing, or have not set things up properly.

(Response: 01020000000000000000000000000000 for example, I believe 0102 is unknown command?)

Please could you give me some idea of how to replicate this command using the DLL:

ST25R3911B_SENDRECEIVE, 02 AA 02 12 03 00 00 01 00 00 00 06 00 01 00 01 06 26 30 30 3A 0D 0A 

I have searched everywhere I can think of and read many posts on the subject, but I just can't find anything that provides enough information for me to get this to work.

A few lines of example calls would be awesome, I have looked at all the demo code that ships with the ST25R3911B Discovery GUI and some stuff google located, but found nothing that helps me understand what I need to do or what I am doing wrong.

05-20-2022 09:31:00	ST25R3911B CONFIGURATION : ISO15693 100% HIGH DATARATE ONE SUBCARRIER
			>>> ST25R3911B_PROTOCOL_SELECT, 0109
			<<< 0000
05-20-2022 09:31:14	FILE SELECTED 
			>>> C:\Users\tim_n\Documents\Message00 - Ident.bin
05-20-2022 09:31:14	FILE CRC
			>>> AF91E5A9
05-20-2022 09:31:35	FILE SELECTED 
			>>> C:\Users\tim_n\Documents\Message00 - Ident.bin
05-20-2022 09:31:35	FILE CRC
			>>> AF91E5A9
 
05-20-2022 09:31:38	---- STARTING FIRMWARE UPGRADE DEMO ----
 
05-20-2022 09:31:38	-> DEMO SETTING : 
 
05-20-2022 09:31:38	PRESENT PASSWORD CONFIG
			>>> ST25R3911B_SENDRECEIVE, 02B302000000000000000000
			<<< 80040078F000
05-20-2022 09:31:38	WRITE CONFIG GPO = B0
			>>> ST25R3911B_SENDRECEIVE, 02A10200B0
			<<< 80040078F000
05-20-2022 09:31:38	WRITE CONFIG MB_EN = 01
			>>> ST25R3911B_SENDRECEIVE, 02A1020D01
			<<< 80040078F000
05-20-2022 09:31:38	WRITE CONFIG MB_WDG = 00
			>>> ST25R3911B_SENDRECEIVE, 02A1020E00
			<<< 80040078F000
05-20-2022 09:31:38	WRITE DYN REGISTER @00
			>>> ST25R3911B_SENDRECEIVE, 02AE020D00
			<<< 80040078F000
05-20-2022 09:31:38	WRITE DYN REGISTER @01
			>>> ST25R3911B_SENDRECEIVE, 02AE020D01
			<<< 80040078F000
 
05-20-2022 09:31:38	-> STARTING DOWNLOADING FIRMWARE 
 
05-20-2022 09:31:38	SEND FRAME (NUMBER : 1)
			>>> ST25R3911B_SENDRECEIVE, 02 AA 02 12 03 00 00 01 00 00 00 06 00 01 00 01 06 26 30 30 3A 0D 0A 
			<<< 80040078F000
05-20-2022 09:31:38	POLLING ON DYN REG UNTIL HOST READ MSG 
			>>> ST25R3911B_SENDRECEIVE, 02AD020D
			<<< 80050043D87F00 43
05-20-2022 09:31:38	READ MESSAGE & CRC : 
			>>> ST25R3911B_SENDRECEIVE, 02AC020000
			<<< 800D000301000004A9E591AFEA2F00
 
05-20-2022 09:31:38	---> CRC SENT BY HOST= A9E591AF
			---> CRC COMPARISON OK 
			---> TRANSFER DONE SUCCESSFULLY 
 
05-20-2022 09:31:38	SEND ACKNOWLEDGE : 
			>>> ST25R3911B_SENDRECEIVE, 02AA02040302000000
			<<< 80040078F000
 
05-20-2022 09:31:38	--------------- FILE TRANSFER ENDED ---------------

[Ulysses HERNIOSUS · Accepted solution]

Hi,

likely you are simply running into a buffer issue. The response to the AA command is one byte longer than the previous responses to the other commands. In ST25R3911B the CRC for NFC-V needs to be checked in software, for doing so it also needs to be received into the buffer provided by the user. If there is not enough space for also putting the CRC the firmware on the board will flag a CRC error.

I was feeding the above strings into ST25R3911B-DISCO on ISO15693 tab and it was working (uses iso15693TxRxNBytes()).

Using iso15693TxRxNBytes() should be ok, it is just a legacy glue layer for rfalStartTransceive()/GetTransceiveStatus().

Best Regards, Ulysses

[tim239955_stm1_stmicro_com]

Ulysses,

Yes that was it! - I had a loop to send the commands and I was not resetting the rxSize each iteration, so it was always being sent as the size returned by the previous command. That was fine until it became too small for the next command 🙂

Just a simple and silly mistake had me spending a whole day looking for the wrong thing. I was thrown by the CRC error! I had got it into my head that meant I needed to use the lower level rfalStartTransceive()/GetTransceiveStatus() functions to resolve it, having read another post which sent me down a rabbit hole.

Thanks for such a prompt reply, it is all working as expected now and is much easier than I had expected. Good catch!

Best Regards

Tim