FTM Firmware Update fails for file sizes > 35kb in ST25 NFC Tap App

[Ener.3]

Dear ST Community,

Our whole team is really irritated by the behavior of a ST25 DV64K-I tag.

We want to use the NFC tag to transmit a firmware hex file (.bin).

For testing purposes, we used the ST25 NFC Tap Android App and after successfully scanning the tag, we went to the feature menu -> ST25DV Demonstrations -> FTM demos.

After deactivating the error recovery (when having it enabled it doesn't work at all for us), clicking on the "firmware update" button and picking a firmware from the phones storage, the transmission starts. Interestingly, when we use a small file like 25 KB, everything is working fine and our bootloader also completely processes & receives the file.

However: The actual firmware we want to transmit is about 95 kb big. Everytime we try to transfer those, it fails at about 35.000 - 45.000 byte. It's always around 50 seconds to 1 minute after the transmission starts. I've also debugged the app and the error code "tag not in the field" is written in the console, although neither the sensor nor the phone is moved (it's lying on the sensor).

Before the transmission fails, the timer is still running for about 10 seconds, but no bytes are being transferred. After the 10 seconds timeout, a “command failed�? toast appears.

We can reproduce the error on 2 separate Samsung devices of different models.

Has anyone else faced this error before and found a solution? We need this for an actual product that is already being sold & produced in a greater scale to avoid manually replacing devices to update firmwares.

Looking forward to your ideas on how to fix this issue or what might be the cause.

Regards

[Ener.3]

I found a weird workaround that might help to find out more about the cause and how to fix the issue...

When the transmitted bytes froze but before the timeout actually occurs and cancels the process entirely, I tried to lock the phone and unlock it again. Interestingly, after unlocking it, the progress resumed and the transmitted bytes incremented, until the process was finished with all 95kb....

So I assume it is a directly NFC or sensor related error, that just blocks a connection for a certain amount of time until the device is somehow "reactivated". As we need this feature for our customers tho, this is currently not a good alternative for us to use in production, so we are still looking for a good fix.

[Olivier L]

Hi,

We're going to support you to find the root cause of this issue.

On firmware side, which board, STM32 and firmware are you using? Did you generate your own firmware from the example provided on https://www.st.com/en/embedded-software/stsw-st25dv001.html?

Would you have some debug traces to provide me (Android side and STM32 side)?

If you are using Android Studio, this is the Logcat content. If you have installed the ST25 NFC Tap application on an Android phone but don't have the development environment, please tell me, I will explain how to get the traces from ADB.

Best regards

Olivier

[Ener.3]

Hi Olivier, thank you for your response.

I extracted the LogCat content from the moment after the app started, right before scanning the NFC tag and just after the FTM firmware update transfer failed. You can find it here: https://pastebin.com/C8WC6xMn

According to our firmware developer (we share this account), we use our own harwdare & firmware, but the problem also appears on X-NUCLEO-NFC04A1 + NUCLEO-WL55JC1 and ST25DV64_DISCOVERY_FW_V1.2.0. Not sure if that answers all your questions.

Regards

David, Flutter Developer

[Olivier L]

Hi David,

Is it a Flutter App or a standard Android app?

Thanks for the log, Here are some comments:

• The command GET_BOARD_INFO is sent but receives no answer. I suspect that it is not implemented on FW side (which is not a problem).

• When the command "writeMsg" is called, there are lot of CMD_FAILED errors (Response: 01 0f). We should understand why. The most likely is that there was a collision between a RF command (= NFC command) and an I2C command. When such collision happens, an error 01 0F will happen.

To investigate further, I recommend to add some debug prints on Firmware side.

Please check also the configuration of the I2C bus. We typically use it at 400kHz but depending of your board (pull up), it can work up to 1MHz.

The goal is to make the I2C communication as short as possible. So the Firmware should not do a constant polling of the ST25DV registers otherwise it will create interferences with the NFC commands.

The MCU can get an interrupt when some data have been put into the Mailbox so it is not necessary to do a polling of ST25DV mailbox control register.

I suggest to check this point first and, if the issue is not solved, to record both the Android logcat and the MCU trace. It would be helpful if every I2C commands sent to the ST25DV tag display a trace and a result.

BTW: When the CMD_FAILED error will be fixed, I recommend to re-enable the error recovery because it worth it: The overhead is low and it will be able to recover in case of error.

Regards

Olivier

[Ener.3]

Hi Olivier, thank you as well. I will ask Ali, the firmware dev, for some debug logs, checking the I2C bus and provide feedback to you asap.

Regarding your first question: The application we are going to build will be in Flutter. However, the problems we are experiencing are still in the native android app from ST25 in the app store. It occurs when debugging the source code from version 3.9.0 (downloaded from ST.com) as well as just launching the official app from the app store. Once we managed to get it running on the native code, I can easily copy the native part and call the relevant native functions (such as chooseFirmware()) from the flutter frontend via a MethodChannel (already tested that successfully). If you know anyone else who managed to get the whole firmware update working in Flutter, that would also be helpful of course.

Getting back at you when we have an update.

Regards

David

[Olivier L]

Hi David,

Ok understood, thanks for those explanations.

FYI, we have a LoRa demo using X-NUCLEO-NFC07A1 (which is very similar to X-NUCLEO-NFC04A1) and NUCLEO-WL55JC1. This demo is using the FTM to transfer some data so you may be interested to have a look.

All the resources are available here:

https://www.st.com/en/embedded-software/stsw-st25010.html

https://www.st.com/en/embedded-software/stsw-st25011.html

https://www.st.com/en/embedded-software/stsw-st25dv010.html

Regards

Olivier

[Ener.3]

Hello Olivier,

as you can see in the code below, we wait for interrupt.

Attached our logfile recorded from our bootloader.

static void ManageGPO( void )

{

 uint8_t itstatus;

 uint8_t st = 7;

 if( EnerRfMessageRec == 1 )

 { 

    EnerRfMessageRec = 0;

   ST25_RETRY(NFC04A1_NFCTAG_ReadITSTStatus_Dyn(0, &itstatus ));

   if( (itstatus & ST25DV_ITSTS_DYN_FIELDFALLING_MASK) == ST25DV_ITSTS_DYN_FIELDFALLING_MASK )

   {

     FieldOffEvt = 1;

   }

   if( (itstatus & ST25DV_ITSTS_DYN_FIELDRISING_MASK) == ST25DV_ITSTS_DYN_FIELDRISING_MASK )

   {

     FieldOnEvt = 1;

   }

   if( (itstatus & ST25DV_ITSTS_DYN_RFGETMSG_MASK) == ST25DV_ITSTS_DYN_RFGETMSG_MASK )

   {

     mailboxStatus = ST25FTM_MESSAGE_EMPTY;

     st = mailboxStatus;

   }

   if( (itstatus & ST25DV_ITSTS_DYN_RFPUTMSG_MASK) == ST25DV_ITSTS_DYN_RFPUTMSG_MASK )

   {

     mailboxStatus = ST25FTM_MESSAGE_PEER;

     st = mailboxStatus;

   }

   ST25FTM_LOG("Interrupt NFC Message rec....%d\r\n", st );

 }

}

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)

{

   if(GPIO_Pin == NFC_GPO_Pin)

   {

      EnerRfMessageRec = 1;

   }

}

[Olivier L]

Hello,

Thanks for the log. I will come back to you soon.

Best regards

Olivier

[Olivier L]

Hi David,

I propose to help you to enable the FTM traces and, then, we can do the same FW upgrade and compare our logs.

If you don't mind, I prefer that we directly work on the version with error recovery.

Here are the instructions to enable the FTM traces:

In st25ftm_config.h, enable ST25FTM_ENABLE_LOG.

You will probably have to update the macro ST25FTM_LOG to route it to your own trace function. Here is what I'm using:

/*! Enables debug traces for the ST25FTM library */
#define ST25FTM_ENABLE_LOG 1
#define ST25FTM_PROTO_ENABLE_PRINT 0
#if (ST25FTM_ENABLE_LOG != 0)
#include "sys_app.h"
#define ST25FTM_LOG(...) do { APP_PRINTF("%d ",HAL_GetTick()); APP_PRINTF(__VA_ARGS__); } while (0)
#elif (ST25FTM_PROTO_ENABLE_PRINT != 0)
#include <stdio.h>
#define ST25FTM_LOG(...) printf(__VA_ARGS__);
#else
#define ST25FTM_LOG(...)
#endif

The macro ST25FTM_HEX2STR can be removed.

Please replace the implementation of the function logHexBuf() with the following code:

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

When this is done, please use the attached file "dummy_64k.bin" to do a FW upgrade and record the traces.

I'm attaching the traces that I get with NUCLEO-WL55JC1 + x-nucleo-nfc07a1 (NB: This is NFC07 and not NFC04 but it is very similar and the same protocol is used).

If possible, I sugest that you order a board x-nucleo-nfc07a1. You will then be able to use it with your NUCLEO-WL55JC1 and try the FW upgrade. IMO, this reference can help to understand what's wrong with your FW upgrade.

I copy paste here the links given in a previous message: All the resources are available here:

https://www.st.com/en/embedded-software/stsw-st25010.html

https://www.st.com/en/embedded-software/stsw-st25011.html

https://www.st.com/en/embedded-software/stsw-st25dv010.html

Best regards

Olivier

[Taksh]

Hello @Ener.3 

I'm working on a similar NFC DFU setup, but using the ST25 DV4KC-I tag instead of the ST25 DV64KC-I tag, and I'm facing the same issue with larger firmware files. Like you, smaller files (e.g., around 25 KB) work perfectly, but the transfer of larger files (around 95 KB) fails at approximately 35,000 to 45,000 bytes. I also see the "tag not in the field" error despite no movement of the phone or sensor, and the transmission times out similarly after about 50 seconds to a minute.

Have you been able to resolve the issue or found any workaround since you last posted? I'd greatly appreciate any updates or insights you've discovered.

Thanks in advance, and best regards!

Taksh.