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

FTM Firmware Upgrade Issue with FEIG MR102 Reader

  • September 21, 2026
  • 1 reply
  • 15 views

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

 

1 reply

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.

Terms & ConditionsAccessibility statement