FastTransferModeCommand byte size read problem?

[Kevin Fisk]

Posted on July 04, 2018 at 01:25

I am writing a custom application that transfers bytes of sensor information from my own custom board to an app I am basing off of the ST25SDK (specifically V1.2.0). My application was failing to read the mailbox (yes, it's enabled) through the RF channel, failing with an 'ST25SDK: transfer finished with error message'. 

When I download the ST25AndroidApp and compile from source, I also ran into this same error message when attempting to read a Data transfer from the tag. In looking at my debug output, it appears to be trying to read 1 less byte than I write in my embedded application. 

More details: So my application writes 18 bytes of data into the Fast Mailbox. When I debug the Read from Tag command, the following line appears to read my 18 bytes written by the embedded (I2C) app. 

int

length =

mST25DVTag

.readMailboxMessageLength()

;

However, further down that function, when I step further into the function and enter into mST25DVTag.readMialboxMessage ...

tmpBuffer =

mST25DVTag

.readMailboxMessage((

byte

) offset

,

size)

;

I eventually run into the following line from within the library (FastTransferModeCommand.class);

return this

.mIso15693CustomCommand.readMsg((

byte

)mbAddress

, this

.computeMsgLengthParam(size)

,

flag

, this

.mUid)

;

this.computeMsgLengthParam(size)  takes my 18 byte message box length, subtracts 1 and reads only 17 bytes from the message box. 

Question:

Can someone help me understand why this is the case? 

Could this be the source of my 'transfer finished with error'  message? 

#st25dv04k #nfc #st25sdk

[Damien G.]

Posted on July 04, 2018 at 12:32

Hi Kevin,

thank you for taking the time to write such a well documented question.

public byte[] readMailboxMessage(int mbAddress, int size) throws STException;�?

The readMailBoxMessage API takes as second parameter the number of bytes to read from the mailbox.

However, the low level Read Message RF command for the ST25DV tagreturns (number + 1) bytes, to be able toread up to 256 bytes (See

https://www.st.com/resource/en/datasheet/st25dv04k.pdf

). This translation (and tricky handling of size = 0) is managed by thecomputeMsgLengthParam() method.

Sothis should not be the source of your problem.

Can youconfirm that the content of tmpBuffer matches the data sent from the I2C?

The

'

transfer finished with error' message comes from the Transfer Task's state machine of the ST25 Android application.

It could occurafter the data transfer,when computing CRC. If values do not match between your embedded firmware and theapplication, then you will get such an error.Try tobypass the checkCrc step and see if this removes it.

Regards,

Damien

[Kevin Fisk]

Posted on July 04, 2018 at 20:32

Thank you for the quick reply Damien. So, yes, the second parameter is indeed 18, which is what I expect and it was in the lower layers where I saw the translation. I had made the assumption (I know, badly) that this was a source of my error. Indeed, the tmpBuffer within readMessage is built up to accommodate and the returned buffer contains all my expected data ( at my expected size). So, to answer your question, indeed I confirm that it matches. 

I wish I had carried on the debug and not made my assumption; where I see it failing is the actual readMessage() appears to be called within readHeader, which takes my message and seems to want to try to parse it. 

I'm still digging into the ST application to learn more however it would seem issue I'm dealing with comes about from within ST25DVTransferTask.java -> run()'s call to prepare which reads the message and tries to parse it like FAST_RANDOM_TRANSFER_FUNCTION. 

In the call stack, it initiates a mEvent = START, with mState= INIT. which then 'prepares' with the mAction of the noted FAST_RANDOM_TRANSFER_FUNCTION. Because of this, readHeader tries to interpret my message as a header which of course, is not what I'd like it to do. My failure (and this is beginning to make sense now) is that my data isn't a header, and naturally fails at;

if

(response[

0

] !=

FAST_IMAGE_DOWNLOAD_FUNCTION

       

&& response[

0

] !=

FAST_RANDOM_TRANSFER_FUNCTION

)

   

return

ERROR

;

which ultimately leads back to the source of my error 

'

ST25SDK: transfer finished with error message'  from this code ....

if

(ret ==

ERROR

) {

    STLog.

e

(

'transfer finished with error'

)

;

So, it would seem that during the INIT phase of the read, it's getting my data and trying to interpret as a header, fails, and so never gets to the point of 'transferring'. At least, that's how it appears to me at the present time. I'll still keep looking at this to try to understand more.

It looks like what I want to do ( read 18 bytes of data) out of the Fast Mailbox would be supported by the present demo application, or there is a bug. I'm still trying to figure out the intent of CHAINED_HEADER_SIZE and how that relates to reading the message or at least the buffer that is returned.  

Your comments and guidance is appreciated. 

[Damien G.]

Posted on July 05, 2018 at 10:26

To illustrate the possibilities of data communication using the Fast Transfer Mode of the

https://www.st.com/content/st_com/en/products/nfc/st25-nfc-rfid-tags-readers/st25-dynamic-nfc-tags/st25dv-i2c-series-dynamic-nfc-tags/st25dv16k.html

, ST has shared the

https://www.st.com/content/st_com/en/products/embedded-software/st25-nfc-rfid-software/stsw-st25002.html

(which you already have) and

https://www.st.com/content/st_com/en/products/embedded-software/st25-nfc-rfid-software/stsw-st25dv001.html

.

The

https://www.st.com/content/ccc/resource/technical/document/user_manual/group0/4d/09/8b/42/28/3f/47/59/DM00288894/files/DM00288894.pdf/jcr:content/translations/en.DM00288894.pdf

 offers a description of the example protocol put in place for communication between the Android app and the STM32 firmware (managing I2C) of the Discovery board.

Of special interest to you, check out page 21 (paragraph 3.2.3 Fast Transfer Mode menu) that describes the protocol.

In the example protocol, at the beginning of the message data stored in the mailbox, there is a header that describes the payload. This header can be a simple header (5-byte size) or a chained header (13-byte size) if the payload spreads over several mailbox transfers.

To transfer 18 bytes of data, the simple protocol will be enough so you shouldn't concern yourself with the CHAINED_HEADER_SIZE for now.