Is there any documentation for the ST25R391xDISCOComm.dll?

[TimLong]

Hi. Is there any documentation for the ST25R391xDISCOComm.dll? I'm trying to use this from a C# application and have managed to get some things working, for example I can identify a type 5 tag, and read its entire 512-byte memory into a buffer in 4-byte blocks. However I want to write some changed data back and I just can't intuit how the 

iso15693WriteBlock() method is supposed to work. It has parameters for received data (I'm writing!) and a final boolean flag named "use_option" which has to be one of the most unhelpful names in the history of programming.

I have looked at the C# demo app and that doesn't write any blocks to the tag so that's no help (same for the C++ and python demos, which are all just copies of each other). I have looked at the C++ header file for the DLL, and that is basically just a mirror of the C# native methods, with no comments or documentation suggestion how anything should be used. Really, as software engineers, we ought to be able to do better than this! Has anyone got this function to work, either in C++ or C#, and could possibly explain to me what parameters it requires and how they are used?

[Ulysses HERNIOSUS]

Hi TimLong,

the functions are more or less direct forwards of  typically the same named function in firmware. Firmware source is available and will tell you more details. In case of this function it seems to have been adapted a bit to make it a bit more friendly.

This DLL layer was more a crutch and initially not intended as public API and it also needs knowledge about the protocols in question. I assume for someone  knowing the actual protocol it should be more or less intuitive

As to use_option: In consider it a good name considering what it does. It sets the in the Write Frame the bit called "Option" in the Request Flags. So Kudos go to ISO defining such a good name.

The cards are returning also a Response Flag and an ErrorCode byte (on firmware as part of the memblock struct) and on GUI as part of the rx buf.

BR, Ulysses

P.S.: Excerpt from firmware source:

/*!
 *****************************************************************************
 *  \brief  Write a single block of a given or selected PICC.
 *
 *  This function writes a single block from a given or selected PICC.
 *  If \a card is NULL then the PICC
 *  needs to be selected using #iso15693SelectPicc prior to calling
 *  this function. If \a card is not NULL then this value is treated
 *  as the PICCs UID.
 *
 *  \param[in] card : PICC whose block should be written.
 *                    If \a card is NULL then this parameter
 *                    is ignored and the information is fetched from the PICC
 *                    priorly selected with #iso15693SelectPicc
 *  \param[in] flags : flags to be sent to the card. The bit
 *                     #ISO15693_REQ_FLAG_OPTION specifies if the response
 *                     must be polled separately.
 *                     This is required by some cards (e.g. from TI) to work
 *                     other cards refuse write command if option flag is set.
 *  \param[out] memBlock : buffer of type #iso15693PiccMemoryBlock_t
 *                      containing the block data to write.
 *
 *  \return ERR_IO : Error during communication.
 *  \return ERR_NOTFOUND : Requested PICC not available. (Not in field)
 *  \return ERR_NOTSUPP : Request not supported by PICC.
 *  \return ERR_CRC : CRC error.
 *  \return ERR_NOMEM : Not enough memory to perform this function.
 *  \return ERR_COLLISION : Collision happened.
 *  \return ERR_NONE : No error, block read out and written to \a memBlock.
 *
 *****************************************************************************
 */
extern ReturnCode iso15693WriteSingleBlock(const iso15693ProximityCard_t* card,
                                uint8_t flags,
                                iso15693PiccMemoryBlock_t* memBlock);

[TimLong]

Thanks for your reply. That is actually quite helpful, I didn't know the firmware source was available. The software support for these devices is actually pretty terrible unless you happen to be using Java (which we are not). As a complete novice to NFC systems it is quite difficult to work with the API at all in its current form, there are just so many challenges and undocumented things. However it is useful to know that the firmware source is available and I'll have a look at that.

Thanks.

[TimLong]

Would you mind helping me a bit further? It would be helpful if you could walk me through how to understand a specific example, for example, how to present a password to unlock writing to user memory.

There is nothing in the DLL that refers to a password. In the tag data sheet (ST25DV04K tag) there is documentation for a Present Password command, code 0xB3, which in formware maps to 

RFAL_NFCV_CMD_PRESENT_PASSWORD.

So it looks like I am looking for an RFAL command for this, again nothing in the DLL that seems obvious.

In the firmware, there is 

rfalST25xVPollerPresentPassword which uses 

rfalNfcvPollerTransceiveReq

In the DLL we have some rfalTransceive* mehods but nothing that directly matches the firmware and without the DLL source code it is hard to infer what to do.

So can you walk me through this? I want to present a password to a ST25DV04K tag so I can write to the user area. What method in the DLL should I use? How does this map to the firmware?

[Ulysses HERNIOSUS · Accepted solution]

Hi,

there is a transceive function: 

iso15693TxRxNBytes(ST25R391xHANDLE handle, const char *tx, uint32_t txSize, char *rx, uint32_t *rxSize, unsigned short response_wait_time)

Fill in the frame from ST25DV datasheet (including flags byte, excluding CRC). Response_wait_time is in ms, so just put a 1 here. Provide buffer for receiving with enough rxSize (please provide at least 4 to be able to perform CRC check, a bit more also doesn't hurt).

BR, Ulysses