FTM using writeMsg command

[shahbaz]

I am performing FTM Demo (Firmware Update) on ST25PC-NFC using ST's STEVAL Reader Board. I have disabled the Fast commands from settings, so FTM is using writeMsg command. Below, I have added a snippet of one of the packets being sent.

2026-03-24 10:04:20.785 writeMsg >> 22AA02329411AE665102E0FF08180C180C180C7FF87FF00000000000000000000000000000000003EC0FFC1C1C180C300C30003000300030003000180C1C1C0FF803F0000000000000000000000000000000007FC07FF018381818180C180C180C180C180C180C181818387FF07FE0000000000000000000000000000000007FF87FF818181818199819801F801F8019801998181818187FF87FF8000000000000000000000000000000003FFC3FFC0C0C0C0C0CCC0CC00FC00FC00CC00CC00C000C003FC03FC00000000000000000000000000000000003EC0FFC1C1C180C300C3000300030FE30FE300C380C1C1C0FFC03F0000000000000000000000000000000007E7E7E7E1818181818
2026-03-24 10:04:20.893 writeMsg << 0000

The packet aligns well with the Write Message request format from the datasheet except for the MsgLength and Message Data part.

• Request Flag: 22
• Write Message Command Code: AA
• IC Mfg Code: 02
• UID: 329411AE665102E0
• Msg Length: FF
• Message Data: 08180C.......E1818181818
• CRC: 

My understanding is that MsgLength refers to the length of the Message Data and not the entire packet. Based on that understanding, MsgLength value should be 238 bytes and Message Data length should be 239 bytes (MsgLength + 1 byte). However, in the packet above, the MsgLength is defined as FF (255 bytes)

Secondly, I also used FEIG MR102 readers to perform the FTM Demo (Firmware Update). Below I have added a snippet of one of the packets.

2026-03-24 10:12:53.258 writeMsg >> 22AA02329411AE665102E02F08206D617920626520627573792E0A506C65617365206D6F766520746865207265616465722E2E2E0A4F72207265636F
2026-03-24 10:12:53.28 writeMsg << 0078F0
writeMsg transceive returns: 00 - Reader status = OK

• Request Flag: 22
• Write Message Command Code: AA
• IC Mfg Code: 02
• UID: 329411AE665102E0
• MsgLength: 2F
• Message Data: 08206D.......207265636F
• CRC: 

From the packet breakdown, the MsgLength is 2F (47 bytes), but if we manually calculate the Message Data length, its 49 bytes, which is not as per the format formula MsgLength + 1byte (48 bytes).

Why is different packets size sent for different readers and how exactly is Message Data size calculated?

[Damien G. · Accepted solution]

Hello Shahbaz,

regarding your first question, my reading is that the MsgLength value of 0xFF (255 +1) size matches the 256 bytes of data that follow. If we take your frame:

---

2026-03-24 10:04:20.785 writeMsg >> 22AA02329411AE665102E0FF08180C180C180C7FF87FF00000000000000000000000000000000003EC0FFC1C1C180C300C30003000300030003000180C1C1C0FF803F0000000000000000000000000000000007FC07FF018381818180C180C180C180C180C180C181818387FF07FE0000000000000000000000000000000007FF87FF818181818199819801F801F8019801998181818187FF87FF8000000000000000000000000000000003FFC3FFC0C0C0C0C0CCC0CC00FC00FC00CC00CC00C000C003FC03FC00000000000000000000000000000000003EC0FFC1C1C180C300C3000300030FE30FE300C380C1C1C0FFC03F0000000000000000000000000000000007E7E7E7E1818181818
2026-03-24 10:04:20.893 writeMsg << 0000

Data block [08180C...181818] is indeed 256-byte long.

For the second example, the MsgLength also matches the length of data that follows: a value of 0x2F means data to follow contains 47+1 = 48 bytes of data. Which is also the case in your example:

---

2026-03-24 10:12:53.258 writeMsg >> 22AA02329411AE665102E02F08206D617920626520627573792E0A506C65617365206D6F766520746865207265616465722E2E2E0A4F72207265636F

---

Data block [08206D...65636F] contains 48 bytes.
The confusion may come from counting the MsgLength byte in the data length. It shouldn't be included as MsgLength strictly quantifies the bytes that follow.

We have set a maximum transfer size of 64 bytes for the FEIG MR102 reader in the ST25PC-NFC software, which explains why packets are transmitted differently for this specific reader. STEVAL reader boards (ST25R3916B for example) do not have the same limit.

Best regards,

Damien

[shahbaz]

Hi Damien,

Thank you for your response.

Sorry for the wrong calculation. Upon rechecking, the data block size is indeed 256byte.

Everything is clear now. 

As for FEIG reader, can we change the transfer size in the SDK to utilize maximum mailbox capacity? 

[Damien G.]

You're welcome :)

The transfer size is here for a reason, to follow the hardware recommendations and observed limitations. But if you want to try with different values, you can modify this file in the ST25PC-NFC software:
ST25PC-NFC\src\com\st\st25pc\model\readers\feig\FEIG_MR102.java
and edit the following constants :

public class FEIG_MR102 extends FEIG_OBID_ISC_Reader {

private static final int FEIG_MR102_MAX_SIZE_TRANSMIT_BYTES = 64;
private static final int FEIG_MR102_MAX_SIZE_RECEIVE_BYTES = 27;
...

}

Beware that changing these values might cause the software to behave in unpredictable ways.

BR,

Damien

[shahbaz]

Hi @Damien G. 

I will give this a try and get back to you.

Thank you.

[shahbaz]

Hi @Damien G. 

I did play around with the following values

public class FEIG_MR102 extends FEIG_OBID_ISC_Reader {

private static final int FEIG_MR102_MAX_SIZE_TRANSMIT_BYTES = 64;
private static final int FEIG_MR102_MAX_SIZE_RECEIVE_BYTES = 27;
...

}

To get maximum mailbox usage, I had to set the TRAMSMIT_BYTES size to 272. 

Looks like it works fine with the FTM demo for firmware update.

[Damien G.]

Ah great, glad it works for you!
I will revisit this value then when we add support for the FEIG MR103 reader.
Thank you for your feedback :)

[shahbaz]

Hi @Damien G. 

Yes, that will be great.

For now, I just copied the java source file of MR_102 with updated values to my custom project.

I am not using the jar package st25pc-model-readers-feig-1.13.0 since it was built using the capped value for MR_102

Regards