Firmware Update for F446 and ST67

[Jerrylin00]

[Part Numbers] NUCLEO-F446RE, ST67W611M1
[Environment] STM32CubeIDE Version 2.1.1, ST67 Firmware Version V1.3.0

[Details]
Currently, the FOTA code generated by STM32CubeMX can only update the ST67 firmware; the F446 firmware cannot be updated.

Furthermore, since the F446 relies on a single-bank flash architecture, we are open to using a wired programming method to prevent the MCU from bricking. However, adopting a wired approach leaves us unable to update the ST67 firmware.

[Questions]

For this architecture, would you recommend proceeding with a FOTA update or a wired update?

If FOTA is the recommended approach, how should we implement the F446 update?
What is the best practice to establish a fail-safe mechanism and avoid bricking the single-bank flash?

If a wired update is preferred, how should we modify the NCP .bat script to ensure the ST67 firmware can also be successfully updated alongside it?

[EPASZ.1]

There is a reference example inside the X-CUBE package for OTA update of the host - you can take a look here Wiki. But you are correct, it cannot be currently generated from CubeMX, although you can take inspiration from it.

You can still create a "wireless OTA" application, even on single-bank host device but it will carry some logical compromises and risks. I think this resource AN5289 part 8.5 describes a good way to implement this even if it is targeted for the STM32WB series.

If you want to do "wired update", then I don't think going with the .bat script is a good choice - this would always require to have some kind of PC doing the update. I suggest looking on this Wiki - it explains the basic principle of the "ST67 OTA". In short, the host MCU can get the data from any source (Wifi, USB, SD card, ...) and use the 3 corresponding APIs to send the data into ST67 and it will handle the update by itself - no need for using UART between host MCU and ST67.

[Jerrylin00]

Hi @EPASZ.1,
Thank you for the explanation. The method you described seems to apply to the scenario where the ST67 firmware is updated via the STM32 host using the STM32CubeMX generated code.

However, my current goal is to flash the chip directly via PC (using an FTDI cable). I am following section "5.2 Flashing the ST67W611M1 using QConn_Flash without an STM32 host (standalone mode)".

Could you provide some insights on why the standalone mode is failing? Are there any other specific hardware requirements (e.g., UART Baud rate limits, power supply transients) for this standalone sequence?

Any insights would be greatly appreciated!