STSW-95HF002 CR95HF PC software Source code and messages over 64 bytes.

[Waller.George]

I'm having an issue with 'patching' the new to accept longer messages than 64 bytes (USD HID limit). On page 43/44 of the AN3954 application note it describes the method of applying this patch, it also talks about a successful return code of "00 02 03 97", however I only get 0xF7 which doesn't appear in the error code list either.

Longer messages still do not work.

Any advice would be great.

Thanks

George

[Brian TIDAL]

​Hi Georges,

this patch is not intended to increase the USB frame length but to increase the maximum message size that can be sent by the PC to the CR95HF when using the CR95HF demonstration board.

When using CR95HFDll_SendReceive API, the send buffer can content a message up to 256 bytes. This buffer is then split in several 64-bytes USB frames and sent to the demo board STM32 microcontroller.  This STM32 microcontroller reassembles the 64-bytes USB frames to rebuild the original message and sent this message to the CR95HF through SPI. The DLL and the STM32 microcontroller act as a relay to convey messages from the user application on the PC to the CR95HF.

This maximum message length of 256 will limit the size of the frame sent to the tag (254 bytes for ISO14443A as a transmission flag is used, 255 for other protocol, see SendRecv command in the CR95HF Datasheet).

The patch described in § 2.4.2 of the AN3954 is only intended to increase the maximum message size that can be sent from the PC to the CR95HF and hence increases the maximum size of frames sent to the tag.

This patch is only needed if you want to sent frames to the tag bigger than 254 bytes (ISO14443A) or 255 (others protocols).

You can manually test the 02A8 command thanks to the CR95HF Development software application:

• select CR95HF button in the "Please, select your RF transponder" window
• in the Tools menu, select Tool box
• click on Extend Transfer Bytes

You should then have the following log message:

12-14-2018 18:56:32	CR95HF CONFIGURATION TO ENABLE CR95HF SENDRECEIVE COMMAND FOR MORE THAN 256 BYTES
			>>> CR95HFDLL_STCMD, 02 A8
			<<< 00020397

The 00020397 reply appears in the text box close to the Extend Transfer Bytes button

If you don't need to sent frames bigger than 254 (ISO14443A) or 255 (other) to the tag, you don't need to use this patch.

Rgds

BT

[Waller.George]

Hi Brian,

When I press that 'Extend Transfer bytes' button, absolutely nothing happens. I can use all of the other features such as getting the IDN but when I try the 'Extend Transfer bytes' button nothing appears in the console log or in the text box immediately to the right of the button. I have noticed that my MCU FW revision is 3.6.0 when section 2.4.2 talks about 3.6.6 is there any way of updating this over the USB?

Thanks

George

[Waller.George]

I have updated the MCU FW version to 3.7.1 however all of the bytes I send after the 56 bytes are random junk when read via the I2C from the FTM on the ST25DV. I'm using the DLL version 1.2 and can set lengths over 256 bytes (I know it's not necessary for this). Before I updated the MCU FW I could send a maximum of 56 bytes in the CR95HF_DEVELOPMENT_SOFTWARE, now I can send 256. This seems like quite a coincidence. Any pointers why this is the case?

[Waller.George]

Attached is the data that is being sent to the data with the CR95HFDll_SendReceive() function and the data that is read out by the MCU via I2C. If I try sending 100 bytes with the development software, it works.

I have also tried copying and pasting the command sent in the development software into my C program. The development software works, the C program does not.

[Brian TIDAL]

Hi Georges,

Would you please check the size of the buffers used in CR95HFDll_SendReceive(strRequest, strTagAnswer):

it must be

 char strRequest[1024];

char strTagAnswer[1024];

Let me know if this solves your issue.

Rgds

BT

[Waller.George]

Hi Brian,

This did not solve my issue. I can read out the contents of the Mailbox with the development software and get the same values as the MCU via I2C.

There must be a better way of implementing this driver than this? HEX numbers in ASCII with a fixed length array is very bizarre.

Thanks

George

[Brian TIDAL · Accepted solution]

​Hi Georges,

the DLL is intended to be used with C and Visual Basic where the messages are sent as ASCII strings for convenience. 

Would you please make sure that the string copied in strRequest[1024] is null-terminated? i.e. make sure to use strcpy, for example strcpy(strRequest,"260100") and not memcpy.

Can you check the DLL revision thanks to the Tool box menu  ?  The Revision should be 1.2.

Can you also check the MCU revision/HW version/IDN.

If this does not solve your issue, would you please share your piece of code when you use CR95HFDll_SendReceive()?

Thanks