C# Application for STEVAL-25R3916BA using ST25R3916DISCOComm.dll

[_JJ_]

Hello

I have been trying to develop a GUI App to communicate with STEVAL-25R3916BA to read & write ISO15693 Tag Type-V. So far with reference from similar other questions asked previously on this forum I have been able to connect to EVAL board and at least read UID of the tag. This I was able to achieve thanks to response from @Ulysses HERNIOSUS responses. To achieve this I have used the example application comes with ST25PC-NFC & ST25 SDK.

 

The example project from ST. for C# does not have read/write example, I have tried my best to perform read/write using APIs from ST25R3916DISCOComm DLL, but so far no success, APIs comes back with no error & no data, if there is no error then why no data? 

I am trying to use iso15693ReadBlock & iso15693WriteBlock from DLL, and I have used ST25PC-NFC to write 0xFF to whole memory of Tag type-V, so I know what I'm reading is okay, as currently API for reading just reads 0 with no error! So I'm not sure if I'm doing anything wrong.

Based on another question (can't find the link), I have explored F/W code as well, dispatcher.c and en.steval-25r3916b-binary\STSW_ST25R018\Middlewares\ST\fw_3916\DISCO-STM32L4x6\Src\iso15693_3.c which defines 

iso15693ReadMultipleBlocks & iso15693WriteMultipleBlocks but based on my investigation on ST25R3916DISCOComm.dll does not have this APIs exported, Am I wrong here? I'm really confused!

(The same Multi-Block Read/Write APIs I can see being called from the console logs of ST25PC-NFC application.)

 I feel like I'm lost in this development, any direction & help would much appreciated.

 

BR

JJ

[Ulysses HERNIOSUS]

Hello _JJ_,

 

to my knowledge the ST25SDK is using only a very limited set of functions from the DLL. Mainly only a basic transceive functionality : txrxBytes() - building all the read block / write block, etc. by hand. 

Read/write multiple commands in ISO15693 are optional and not supported by all tags.

I think for further being able to help you, you will need to share the sequence of executed DLL functions with all its parameters and also the returned data/status.

 

BR, Ulysses

[_JJ_]

Thank you Ulysses. I was expecting a response from you.

Sure I can share my sequence which I am executing in C# application for further discussion.

About ISO15693 tag type-V, I am using is ST25TV16K. As I can read/write on this tag using ST25PC-NFC, where from console logs I can see that it definitely supports Multiple block Read/Write, which I can also confirm from its Datasheet.

1. When application launches, I use GetST25R391x() to connect with STEVAL-25R3916BA, which is always successful and I have the handle to the board
2. To initiate ISO15693, as I am only interested for this tag type, using Initialise() with following parameter. (This parameters are same as Demo Application, I tried with Fast Mode set to TRUE, but then reader struggles with inventory request, not sure why?!)
   • ST25R391x_Dll.iso15693Initialise(DeviceHandle, 0, false)
3. Using sendInventoryRequest(), I'm trying to read available tag and it's UID.
   • ST25R391x_Dll.iso15693sendInventoryRequest(DeviceHandle, 0, InventoryBuffer[10], ref MaxCards = 1)
4. First I tried to read of the tag, as mentioned earlier for readability I have written 0xFF into all tag memory including CC bytes location. So I know whatever block I read I should expect 0xFF. For reading using ReadBlock() function.
   • ST25R391x_Dll.iso15693ReadBlock(DeviceHandle, UID = 8 bytes as per DLL, 0, card_data = sybte[8], data_len = uint[8])
   • Here, I do not ambition to read whole tag, if I can read at least one block which is 8 byte, that is the reason my buffer size is 8.
   • About blocknr, tbh I still do not understand this parameter, I tried to from F/W implementation and there is no clear documentation from ST. Initially I thought it is block number, so I kept it 0, I want to read block-0. Am I correct here?
   • UID param is driving me bit crazy, during initial time of development Just for clarification I initially provided UID in reverse order, the way it is being displayed on user interface, but that did not work, then I realised Tag Type-V UID requires to be send back as is, the way it was read-back from inventory. Post this correction my APIs are succeeding but no data as mentioned above.

I think, if read can be corrected then I might be able to write easily, correct me if my thinking is wrong. I can bring write part once read is sorted.

@Ulysses HERNIOSUS I hope this will help you determine what could be wrong here.

 

BR

JJ

[_JJ_]

I was just playing around iso15693GetSystemInformation() function: and got this, comparing this output with F/W code, data mapping makes sense but the outcome of data does not make sense to me, any idea?

Received from Tag type-V: [HEX: 00 0B 92 D6 1C 62 03 48 02 E0 00 00 48 E4 43]

F/W Code Sys Info Structure:

Based on converting these values from signed bytes to HEX, I can see bytes[2:10] are UID, which makes byte-0 & 1 flag & infoflags respectively. Leaving last remaining 5 bytes as dsfid, afi, memblocks, memblockSize, icRef.

Where, Mem Blocks is 72, which does not look right, I would expect 512 blocks of size 4 bytes as per datasheet. This is off putting my understanding, I feel like a ***.

[Ulysses HERNIOSUS]

Hi JJ,

 

Reading the data sheet of ST25TV16K (6.4.22) the Get System Info is as expected: the info flag 0x0b means no block information provided, E4 43 I presume to be CRC16.

For the iso15693ReadBlock(): block_nr refers to the Block Number parameter of "6.4.6 Read Single Block". I don't see in your explanation the actual data fed in nor the return (status) code and data after execution. UID I think you could also leave at NULL - the function should then execute the Read Single Block without UID in broadcast mode.

Ulysses

[_JJ_]

Thank you Ulysses for looking into this.

About System Info of tag, your explanation make sense. I ignored the datasheet there because I was looking at F/W source code for ISO15693 for EVAL board, which seems to be misleading.

Coming back to ReadSingleBlock(), I tried supplying null for UID, but the function return back with Timeout error.

With UID supplied, function succeeds with NoError code but no data received.

Based on Datasheet, I expect 8 byte in return,

 

PS: In code snip, you see call to Select() as well, I thought (naively!) I may have to select a tag before this operation even though I knew ReadBlock() calls take UID as argument, as I was desperate to get a result I tried it but I commented the code as there was no improvement!

 

[Ulysses HERNIOSUS]

Hi JJ,

this is a C style interface. With data_len/sizeof_data you need to communicate the size of the buffer you provide to the DLL and after the function returns the data_len will be adapted to the actual returned size. You will need to feed in a pointer to a uint32_t with value of 8.

I suspect in your case the firmware was provided with a zero length buffer which it was not filling.

About UID, likely the story goes that the function with UID=0 goes then into using selected mode, likely in this case you will be needing the Select().

 

BR, Ulysses

[_JJ_]

Thank you so much Ulysses.

I got what you mean, I was supplying wrong data_len/sizeof_data, as I had an array declared but all with 0 data by default, as soon as I corrected that I  am seeing data now. In my case as I have flashed whole tag memory with 0xFF pattern I see -1 as data which is 0xFF in HEX.

I tried WriteSingleBlock as well, and it is working now as expected. I am able to read/write single block at a time.

For WriteSingleBlock I had to call Select tag first, otherwise it does not work, on the other hand ReadSingleBlock seems to not have dependency on Select UID function. It also worked with UID as null as you suggested earlier.

 

Single Read & Write can only work up to 256 blocks, my tag has 512 blocks, looking at the remaining APIs from DLL it is not making any sense to me what I should use for extended Read & Write operation. Is there anyway I can achieve multi block read & write?

[Ulysses HERNIOSUS]

Hi,

 

for the other commands you need to build them on your own using iso15693TxRxNBytes() or txrxBytes(). I think the first one is easier to use for you. Please be cautious about allowing space for the CRC for these two functions - otherwise they may flag a CRC error (as not being able to check it).

BR, Ulysses

[_JJ_]

Thank you for all your guidance so far and heads up. 

Really appreciate your support on this community.

 

Let me try building commands and see how it goes, if any further help needed will come back to annoy you again. :)  

[_JJ_]

Hello again @Ulysses HERNIOSUS 

 

Thank you for your help so far, as per your suggestion I have been trying to build custom commands, in order to do that I am using ST25PC-NFC tool's Frame Builder, as I am only interested for ISO15693 for me it is Iso15693FrameBuilder tab. Again to start simply, to understand how to use iso15693TxRxNBytes() I am just trying to send Get-System-Info of the tag. So I built a frame using the tool and tried the same via tool to make sure I'm not sending any nonsense command, it works fine.

I am sending the same frame via my program, but it is ending up in an ERROR 01, with Error code 02 Command not recognised (format error). Remaining two bytes are CRC16 (X-25).

As I was not getting expected results I started retrospection of what could be wrong, every single time I was ending up doubting on Request_Flag byte, which is common input for any command, I started playing around it, tried to generate possible values via ST215PC-NFC tool, tried to execute it on tool, and then use the same Request Flag value to see if works on my program, but no success so far.

My code to send Get-Sys-Info command:

For, CRC-16, in snippet it shows as ZERO, as I have left it like that, in other case I have calculated CRC16/X-25 and provided as part of command, in both case it has failed with the same Error Code. I have also maximised the timeout.

Could you please guide me, what am I missing here?

 

[Ulysses HERNIOSUS]

Hi JJ,

With the API that you are using you should not use the CRC, it will be automatically generated inside firmware and appended. In your case you would end up with two extra data bytes followed by the real CRC.

AFAIK anyhow the firmware will adapt the Request Flag to fit the physical comm params - One subcarrier + high data rate, so your pre-calculated CRC would even be incorrect.

Only with the Physiscal variant (iso15693PhyTxRxNBytes) you need to supply a pre-calculated CRC.

BR, Ulysses

[_JJ_]

Just Brilliant @Ulysses HERNIOSUS 

I have tried multiple custom commands based on your suggestion and it is working very well! I can not thank you enough for your help & guidance on this. Without it it'd be not possible to get to this stage for me.

Keep helping the community, Cheers!