cancel
Showing results for 
Search instead for 
Did you mean: 

Unknown byte received from Tag when reading max mailbox size.

perencia-wc
Associate II

Hi,

I'm using an ST25DV64KC tag to communicate with an Android app using the st25 sdk and the Mailbox. The problem arises when the app reads a message of the maximum mailbox capacity. In that case, an 0xE4 character appears as the last character but I'm pretty sure the firmware didn't put it.

Here is an example of an interaction

2025-05-12 08:32:09.466 12263-19515 Iso15693CustomCommand   com.wavecontrol.mtiotmobileapp       D  ==> Send readMsgLength command: 22 ab 02 7f 46 b6 7c 67 51 02 e0

2025-05-12 08:32:09.480 12263-19515 Iso15693CustomCommand   com.wavecontrol.mtiotmobileapp       D  Response: 00 ff

2025-05-12 08:32:09.483 12263-19515 Iso15693CustomCommand   com.wavecontrol.mtiotmobileapp       D  ==> Send readMsg command: 22 ac 02 7f 46 b6 7c 67 51 02 e0 00 ff

2025-05-12 08:32:09.588 12263-19515 Iso15693CustomCommand   com.wavecontrol.mtiotmobileapp       D  Response: 00 02 7b 22 6a 73 6f 6e 72 70 63 22 3a 22 32 2e 30 22 2c 22 72 65 73 75 6c 74 22 3a 22 54 30 36 3a 31 34 3a 34 35 2e 33 30 36 20 52 65 63 65 69 76 65 64 20 67 65 74 5f 69 6e 66 6f 5f 6d 65 61 73 75 72 65 5c 6e 5b 49 5d 20 32 30 32 35 2d 30 35 2d 31 32 54 30 36 3a 31 34 3a 34 38 2e 37 32 31 20 4e 46 43 20 73 65 73 73 69 6f 6e 20 73 74 61 72 74 5c 6e 5b 49 5d 20 32 30 32 35 2d 30 35 2d 31 32 54 30 36 3a 31 34 3a 34 38 2e 37 32 32 20 52 65 73 74 61 72 74 65 64 20 6f 6e 65 2d 73 68 6f 74 20 74 69 6d 65 72 20 4e 46 43 20 73 65 73 73 69 6f 6e 20 74 69 6d 65 72 20 77 69 74 68 20 74 69 6d 65 6f 75 74 20 31 30 30 30 30 20 6d 73 2e 5c 6e 5b 49 5d 20 32 30 32 35 2d 30 35 2d 31 32 54 30 36 3a 31 34 3a 34 38 2e 37 32 37 20 52 65 63 65 69 76 65 64 20 67 65 74 5f 69 6e 66 e4

 

As can be seen, the retrieved message length is 255, which according to the datasheet is the size of the message in the mailbox - 1.

perenciawc_0-1747031803118.png

Then I issue a readMsg command passing it the 0xff, so it should read 0xff + 1 bytes

perenciawc_1-1747031944806.png

But at the end I get that 0xe4, which I'm confident wasn't put by the host side. As a result I lose one byte.

That doesn't seem to happen when writing less than 256 bytes.

Where that character may come from? I've tried putting several different messages in the mailbox but the last character is always 0xe4.

 

1 ACCEPTED SOLUTION

Accepted Solutions
JL. Lebon
ST Employee

Hello, 

I think that if the getMaxReceiveLengthInBytes reports 253, it is probably a good idea to limit your frames to 253. There is a reason why this reports 253 and not 255.

I cannot predict what kind of miss behavior will happen if you exceed max the value announced by the phone, so I can't explain the E4 value, but I can try to guess: may be, when the buffer overflow happens, the last byte of the receive buffer is overwritten by new incoming bytes, so maybe E4 is the value of the last byte transmitted, which is the second CRC byte.

Best regards.

View solution in original post

3 REPLIES 3
JL. Lebon
ST Employee

Hello, 

The ST25DV64KC is able to transmit a frame that contains the 256 bytes of data from the mailbox,
But is the phone capable of receiving such a long frame?

When transmitting 256 bytes of data from tag to phone, the frame size will be 256 bytes long (256 byte of data + 1 byte of response flag + 2 bytes of CRC).

If the phone's receive buffer is 256 Bytes size, there is a risk that last bytes of data cause an overflow.

So maybe you can check the phone capabilities regarding received frame size.

Best regards.

Hi,

I've already thought about that. getMaxReceiveLengthInBytes reports 253, but it is clear that i can receive more, in fact i receive 255. If the problem was that, I'd expect to receive some exception from the library or get the message truncated in some way up to 253, but that's not the case. And besides, that, why 0xE4?

JL. Lebon
ST Employee

Hello, 

I think that if the getMaxReceiveLengthInBytes reports 253, it is probably a good idea to limit your frames to 253. There is a reason why this reports 253 and not 255.

I cannot predict what kind of miss behavior will happen if you exceed max the value announced by the phone, so I can't explain the E4 value, but I can try to guess: may be, when the buffer overflow happens, the last byte of the receive buffer is overwritten by new incoming bytes, so maybe E4 is the value of the last byte transmitted, which is the second CRC byte.

Best regards.