Skip to main content
T
TimLong
Graduate II
February 23, 2024
Solved

Is there any documentation for the ST25R391xDISCOComm.dll?

  • February 23, 2024
  • 1 reply
  • 1486 views

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?
    This topic has been closed for replies.
    Best answer by Ulysses HERNIOSUS

    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

     

    1 reply

    U
    Ulysses HERNIOSUS
    Technical Moderator
    February 23, 2024

    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);

     

      T
      TimLongAuthor
      Graduate II
      February 26, 2024

      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.

      Terms & ConditionsAccessibility statement