FTM Firmware Update fails for large file size in ST25 NFC Tap App

[Taksh]

Dear ST Community,

I’ve been working with the ST25 DV4KC-I NFC tag to transfer firmware for our product, but I’m encountering persistent issues with larger firmware files.

Here’s the process I followed: I use the ST25 NFC Tap Android App to select the NFC tag and navigate to ST25DV Demonstrations → FTM Demos. When I initiate a firmware update with a smaller file (around 25 KB), the transfer completes successfully, and our bootloader processes the file without any issues.

However, when I try to send a larger firmware file (~ 200KB), the transmission consistently fails between 35,000 and 45,000 bytes. The app logs the error "No response received," and the transmission halts around 50 seconds to 1 minute into the process. For the last 10 seconds, no data is transferred before timing out. Both the phone and tag remain stationary throughout.

I’ve tested this issue on multiple Samsung devices, but the problem persists. The smaller files transfer without any issues, so this seems to be size-related.

Interestingly, I came across a similar thread discussing a failure in firmware transmission for files larger than 35 KB:

https://community.st.com/t5/st25-nfc-rfid-tags-and-readers/ftm-firmware-update-fails-for-file-sizes-gt-35kb-in-st25-nfc-tap/td-p/68727 

I followed the steps suggested, including enabling FTM traces.

Enabled FTM logging in st25ftm_config.h with ST25FTM_ENABLE_LOG.
Integrated the logging function using the following setup:

#define ST25FTM_ENABLE_LOG 1
#include "sys_app.h"
#define ST25FTM_LOG(...) do { APP_PRINTF("%d ",HAL_GetTick()); APP_PRINTF(__VA_ARGS__); } while (0)

Updated the logHexBuf() function as recommended:

void logHexBuf(uint8_t* buf, uint32_t len)
{
if(len > 0)
{
for (int i = 0; i < len; ++i)
{
APP_PRINTF("%02x ", buf[i]);
}
APP_PRINTF("\r\n");
}
}

Despite enabling error recovery and logging, the issue remains unresolved. I have reviewed the available resources from ST’s website but have yet to find a solution.

I would appreciate it if someone could provide a solution to this problem or let me know if I might be missing any important configuration steps.

Any advice on resolving this would be very helpful!

Best regards,
Taksh Patel

[Cedric Dalban · Accepted solution]

Hello Taksh,

looking at your message I have some few comments.

1) The way you enabled the traces makes me think you are using a quite old FTM driver. The ticket you are refering to in your message was precisely based at the time on this old FTM driver version. A new version (v2.2.1) of package STSW-ST25DV002 has been recently delivered on st.com.
This version contains major updates for FTM component with many clean ups and bug fixes.
The new version is also aiming to make the FTM component to be fully agnostic from any HW/BSP; taking the assumption that all BSP related code is now embedded in a single header and a single source file (see point 2)).
The FTM component is also now providing some means to handle events through related callbacks, this will ease integration in multitask environments.

2) The new package contains a file (...\Middlewares\ST\ST25FTM\Docs\PortingFTM.txt) listing main actions to port the old FTM in your application to the new version.

3) Another package on st.com (STSW-ST25R-LIB) is using the new FTM component and is providing some code example. I warmly recommend you to have a look to the provided examples.

4) You can find some few documentation on st.com related to the FTM:
- AN5512: details the FTM component APIs
- UM2949: details the FTM protocol
- UM3078: details the use of FTM component on Linux

5) Once you would have finalized the porting, the traces are simply enabled the following way:
- In st25ftm_config_hal.h, just set the define ST25FTM_ENABLE_LOG to 1

With this define set to 1, the FTM traces should be outputed on UART (baudrate 115200)
could you please share the traces you get when you upload the "big" firmware ?

Hoping all these info will help.

Best regards,
Cedric.