Skip to main content
shahbaz
Associate III
September 21, 2026
Question

FTM Firmware Upgrade Issue with FEIG MR102 Reader

I previously experimented with performing the FTM Demo (Firmware Upgrade) in ST25PC-NFC on an ST25DV Discovery board, using both the STEVAL-25R3916B and FEIG MR102 readers. The demo worked successfully with both readers, although there was some difference in transfer speed.

 

We are now looking to implement OTA firmware updates on our NFC-enabled product, which is based on a PIC microcontroller. We have integrated the ST middleware into our application and are currently testing the firmware upgrade functionality using FTM.

 

The firmware upgrade works correctly when using the STEVAL-25R3916B reader. I have attached the relevant logs below.

 

However, when using the FEIG MR102 reader, the firmware upgrade does not work correctly. After comparing the ST logs, it appears that there is a difference in the timing and behaviour of the writeMsg calls between the two readers.

 

With the FEIG MR102:

  • The first packet is always transferred successfully.

  • Almost all subsequent packets require a second attempt before they are transferred successfully.

  • This effectively doubles the transfer time.

  • There is also an additional delay between packets that does not appear when using the STEVAL-25R3916B.

 

I found that the ST middleware introduces this delay between packets. To test this, I added:

mFtmCommands.setMinTimeInMsBetweenSendCmds(0);

before calling:

mFtmCommands.sendCmdAndWaitForCompletion(...);

 

This removes the additional delay between packets. However, the main issue remains: subsequent packets still require multiple attempts to transfer successfully with the FEIG MR102.

 

For comparison, I have included logs below showing the packet transfer behaviour with both readers.

My questions

  1. Is the inter-packet delay controlled by the ST25 SDK expected to be required for FTM communication, or is it safe to set setMinTimeInMsBetweenSendCmds(0)?

  2. Is there any additional timing requirement or configuration that needs to be considered when using the FEIG MR102 reader for FTM?

  3. Could the repeated TAG_NOT_IN_THE_FIELD / unsuccessful first attempts for subsequent packets be related to the FEIG reader's RF or ISO15693 timing?

  4. Is there anything specific that needs to be implemented or configured in the reader integration (writeMsg) to support reliable FTM packet transfers?

I have included two packet-transfer examples from each reader below so that the timing and behaviour can be compared.

 

STEVAL-25R3916B:

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: sendFtmData: Data Size = 49409 Bytes

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: mState = PREPARE_PACKET

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: FTM Semaphore received

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: sendNextPacket

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: preparePacket

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: ==> Send Packet 0 (256 Bytes) from Segment 0

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: First Packet. TotalLengthField Present

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: Data : 04 00 00 …..  ff 4b 90

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: mState = SEND_PACKET


2026-09-21 12:27:17.51 writeMsg >> 22AA02438F33A2685002E0FF040000….FF4B90
2026-09-21 12:27:17.619 writeMsg << 0000

 

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: mState = PREPARE_PACKET

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: sendNextPacket

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: preparePacket

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: ==> Send Packet 1 (256 Bytes) from Segment 0

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: Middle Packet

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: Data : 08 10 00 …. 01 14 00

Sept 21, 2026 12:27:17 PM com.st.st25sdk.STLog i INFO: mState = SEND_PACKET


2026-09-21 12:27:17.62 writeMsg >> 22AA02438F33A2685002E0FF08100….011400
2026-09-21 12:27:17.731 writeMsg << 0000

 

 

FEIG MR-102 Reader:

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: sendFtmData: Data Size = 49409 Bytes

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: mState = PREPARE_PACKET

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: FTM Semaphore received

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: sendNextPacket

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: preparePacket

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: ==> Send Packet 0 (256 Bytes) from Segment 0

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: First Packet. TotalLengthField Present

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: Data : 04 00 00 …. ff 4b 90

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: mState = SEND_PACKET


2026-09-21 12:05:12.523 writeMsg >> 22AA02438F33A2685002E0FF040000…FF4B90
2026-09-21 12:05:12.61 writeMsg << 0078F0
writeMsg transceive returns: 00 - Reader status = OK

 

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: mState = PREPARE_PACKET

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: sleep 12 ms

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: sendNextPacket

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: preparePacket

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: ==> Send Packet 1 (256 Bytes) from Segment 0

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: Middle Packet

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: Data : 08 10 00 ... 01 14 00

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: mState = SEND_PACKET


2026-09-21 12:05:12.624 writeMsg >> 22AA02438F33A2685002E0FF081000...011400
2026-09-21 12:05:12.732 writeMsg <<
Reader status = No tag detected or no response from tag!

 

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog w WARNING: error during sendPacket: TAG_NOT_IN_THE_FIELD

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: ==> Send Packet 1 (resend)


2026-09-21 12:05:12.734 writeMsg >> 22AA02438F33A2685002E0FF081000...011400
2026-09-21 12:05:12.821 writeMsg << 0078F0
writeMsg transceive returns: 00 - Reader status = OK

 

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: mState = PREPARE_PACKET

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: sleep 13 ms

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: sendNextPacket

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: preparePacket

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: ==> Send Packet 2 (256 Bytes) from Segment 0

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: Middle Packet

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: Data : 08 8a 00 ... 25 01 14

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: mState = SEND_PACKET


2026-09-21 12:05:12.835 writeMsg >> 22AA02438F33A2685002E0FF088A00...250114
2026-09-21 12:05:12.942 writeMsg <<
Reader status = No tag detected or no response from tag!

 

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog w WARNING: error during sendPacket: TAG_NOT_IN_THE_FIELD

Sept 21, 2026 12:05:12 PM com.st.st25sdk.STLog i INFO: ==> Send Packet 2 (resend)

 

2026-09-21 12:05:12.942 writeMsg >> 22AA02438F33A2685002E0FF088A00...250114
2026-09-21 12:05:13.03 writeMsg << 0078F0
writeMsg transceive returns: 00 - Reader status = OK

 

3 replies

JL. Lebon
JL. Lebon
ST Employee
September 21, 2026

Hello, 

Your problem seems to be definitely a timing issue.
From your traces, it seems that you are facing a collision between RF and I2C. This marker of this is that there is no answer to the write message command.

In FTM, the microcontroller is informed of a successful write message command by an interrupt. It then have to read a status register to check which interrupt has been triggered, through the I2C bus. Then it reads the MB_CTRL_Dyn register and the MB_LEN register to know the nature and length of the message. It can then read the message. All done through I2C commands.

When an RF command (like the write message command) arrives when the MCU is already accessing the ST25DV through I2C (e.g. checking status register or reading/writing a message in the mailbox), there is a conflict of access that can result in 2 behaviors (see datasheet chapter 5.3 Interface arbitrartion):

  • if the RF command is in non-addressed mode, or in select mode, the RF command is answered with error 0x0F.
  • if the RF command is in addressed mode, the RF command is not answered.

From your logs, I can see that you are using the addressed mode for the write message command. As there is no answer to the command, the most probable is that there is concurrent I2C access from the MCU. You can check that hypothesis by using the non-addressed mode or (better) by using the selected mode. In non-addressed or selected mode, you should see an error 0x0F instead of no response.

Now, I don’t know why there is a timing difference between the two readers, but FTM must always be fine-tuned in term of timing between RF and I2C command polling to avoid collisions between RF and I2C access to the ST25DV.
You can try to debug with an oscilloscope by acquiring both RF signal on a channel (a simple one loop antenna is enough to see RF frames) and I2C on another channel and see where the collision happens.

 

Best regards.

shahbazAuthor
Associate III
October 11, 2026

Hi ​@JL. Lebon,

In a discussing from an earlier thread (mentioned above), I removed the FEIG_MR102_MAX_SIZE_TRANSMIT_BYTES cap for MR102 reader. I set the size, so that FTM can use the max 256b.

    // Should be 268 (256 byte data packet + 12 byte header) but setting it to 272. 
    // In FEIG_OBID_Generic_TransceiveImplementation definition, max size will be set 
    // to 268 (272 - 4) based on (mMaxTransmitBuffer - ISO_15693_OVERHEAD_SIZE_IN_BYTES).   
    // Overhead is defined as 4 in that file

    private static final int FEIG_MR102_MAX_SIZE_TRANSMIT_BYTES = 272; 
    private static final int FEIG_MR102_MAX_SIZE_RECEIVE_BYTES = 27;

 

Although the new limits worked with the demo firmware upgrade for ST25DV Discovery board, but it failed on our NFC enabled device. Upon changing the limits back to 64bytes, the transfer was completed with no retries for any packet. 

I tried bumping up the limit from 64 to 128, and eventually to 256bytes. The transfer works on 256b, which makes the data packet size 240bytes.
 

Is it safe to use these limits (mentioned above) for MR102 reader? I already tried multiple instances of the demo with these limits and it works fine.

Damien G.
ST Employee
October 12, 2026

Hello shabhaz,
 

The limitation in the ST25PC-NFC software is there for legacy reasons (not linked to FTM transfers). But the FEIG MR102 is able to work with frame sizes of 256 bytes so the values you selected (payload size of 240 bytes) should be safe for use with a ST25DVKC tag.

Best regards.

Terms & ConditionsAccessibility statement