Is there any source code available for ST25R3916-DISCO desktop App (either one)? Or at least a protocol document for the USB protocol therein?

[RLee.4]

..

[Ulysses HERNIOSUS]

Hi,

in general we don't provide the source of the ST25R3916-DISCO GUI. However you may find the following useful:

1. The source code of the firmware. File dispatcher.c has all the implemented commands, mostly also together with documentation
2. On PC side there is a DLL and demo projects for using the interface to the board.

Please let me know if one it fits your needs!

Regards, Ulysses

[RLee.4]

Ah.... The PC side DLL demo, I found after looking a little more closely... the problem is that the installer put it in the documents folder of the user installing it rather than the documents folder of the user using it. On my machine I need to go to a local admin account to do installations at all. I've saved that somewhere I can actually use it.

On the embedded side, I did find dispatcher.c down in the middleware section... .E:\STSW-ST25R011\ST25R3916_DISCO_v1.1.0\Middlewares\ST\fw_3916\DISCO-STM32L4x6\Src

I'll take a look at this stuff today... Thanx!

[RLee.4]

I'm having a really hard time getting this to load up the DLL on Win10. If I put the CSharp_Dll391x_demoexe that's in the EXE_Demos into the directory that the ST applications are installed in, it loads the DLL that's there but that one was down level enough that it couldn't find some entry points. If I put the DLL that's in the EXE_Demos into that directoy, it loads but it get's the firmware version on the board wrong and then can't find an entrypoint of _iso_14442b_ST25TB_Initiate in it (I would want to use the ISO 15693 anyway so that isn't all that bad maybe.)

So the question is why it can't find/load the DLL when it's in the structure for the source code.

The CPP version of this can't find certain Qt Dlls -- I haven't attempted that one in the installer directory

[Ulysses HERNIOSUS]

Hi,

I was playing now a bit and got it working. It seems we made a mistake by only putting ST25R3916DiscoComm.dll in the Exe_Demos folder. Much more is required here. I was trying to copy everything from the GUI installation folder - still without success. We need to investigate here.

Reporting of C# seems to be wrong, I think it finds the DLL but chokes on subsequent DLL errors.

However I have a working solution as well: Install QT5 (best to use QT5.7 and put then the folder C:\Qt\Qt5.7.0\5.7\msvc2015 on the PATH variable.

We will investigate and let you know once we know more.

Ulysses

[RLee.4]

I installed an older copy of Qt on my machine and found the missing DLLs to get the CPP version of the demo up and running, at least on the tags I'm interested in.

So, the source code is only so good at solving some issues of programming. I can waltz code to the point where it's looking at the delcaratives for the DLL connections so these are sort of sparse...

In particular I need to write the tags I've found. I appear to be able to enumerate the tags and then select them one at a time. The write function:

EXTERN_C ST25R391xAPI ST25R391xComError APIENTRY iso15693WriteBlock ( ST25R391xHANDLE handle, const char uid[8], unsigned char blocknr, const char data[], size_t data_size, char *rx, size_t *rxsize, bool use_option);

Is more than a little opaque to me. I should be able to figure out most everything but the rx and rxsize pointers (I'm writing, is this actually reading??). Also the use_option I haven't found docs for that.

When I try this by selecting the tag, writing a couple of blocks and then use iso15693StayQuiet() on it, I get an error 9 on the write.

Any hints for me on this?

[Ulysses HERNIOSUS]

Hi,

the rx and rxsize puzzled me a bit as well. It seems to have been added for completeness to receive any extra bytes would could have been returned by the command over USB. In this case there aren't any as you can find in dispatcher.c (firmware):

 case 0xd8:
 if (bufSize < ISO15693_UID_LENGTH + 3) return ERR_PARAM;
 memBlock.actualSize = bufSize - ISO15693_UID_LENGTH - 2;
 memBlock.blocknr = buf[9];
 ST_MEMCPY((uint8_t*)memBlock.data, buf + 10, memBlock.actualSize);
 err = iso15693WriteSingleBlock(cardptr, buf[0], &memBlock);
 break;

This file + used declaration may help you a bit more in understanding.

Regarding use_option: Please consult ISO15693 for details and support of the so-called "OPTION" flag. If unsure say false.

Regards, Ulysses

[RLee.4]

I found out from the above that this call is wanting to write exactly one block even tho it's pretending to write any number of them. Therefore if the datasize is anything but 4 it doesn't work. I can write multiple blocks, one at a time with this, no problem...

[Ulysses HERNIOSUS]

Hi,

name of the function is WriteBlock(), not WriteBlocks() or WriteBytes(). I have to admit the difference is maybe a bit subtle if you are not aware of the protocol details of ISO15693: One block can be contain between 1 and 32 bytes of data. That's why this function takes a variable length buffer as param.

However all ST25(D|T)V and M24LR have a memory size of 4 bytes. Only when you use WriteBlock with 4 bytes it will be accepted by our VICCs.

Regards, Ulysses