2021-05-13 03:59 PM
Hardware:
MCU: STM32L4R9ZGJ6
OSPI Flash (512 Mb): MT35XL512ABA1G12
Software:
STM32Cube_FW_L4_V1.14.0
STM32CubeIDE 1.6.0
TouchGFX 4.13.0
Hello,
I am working on over-the-air device firmware updates for the STM application code and GUI assets stored in a memory mapped OSPI flash. I would like to be able to update the OSPI GUI assets independently from the application firmware since the GUI assets may not always be updated and can be up to 64 MB compared to the application flash size of 2 MB.
Question: Does TouchGFX create a version or timestamp in the generated GUI source files that I can use for firmware update version comparisons?
My goal is to be able to compare the version of the GUI assets in the OSPI flash to the version stored on a server, and update only if needed. However, I don't see if or where TouchGFX tags the generated GUI code with any version or date information.
Thanks,
Derek
Solved! Go to Solution.
2021-06-18 02:08 PM
I found my own solution. I compare the binary size and crc of the GUI assets in OSPI flash and compare that to a locally downloaded file. It's a unique enough "version" identifier to fulfill my needs.
Edit: This doesn't actually work as well as I thought it would. The issue is that you can't prefill the CRC and size on first device boot because the application doesn't know how large the GUI asset binary is in OSPI.
A better solution that I found is to use TouchGFX Designer post-build steps to call SubWCRev.exe to generate a SVN version file with #defines that can be reference by the application. The application then contains the following:
const uint32_t m_gui_version __attribute__((section(".guiVersion"))) = SW_GUI_VERSION;
Where SW_GUI_VERSION is the #define with the SVN version generated by SubWCRev. Section .guiVersion is added in the linker at the beginning of OSPI as so:
/* GUI version - Make sure this is above ExtFlashSection */
.guiVersion ORIGIN(OCTOSPI) :
{
KEEP(*(.guiVersion)) /* Keep variable even if not referenced */
} >OCTOSPI
/* Constant data into "OCTOSPI" Memory Mapped Flash type memory (TouchGFX GUI generated assets) */
ExtFlashSection :
{
*(ExtFlashSection ExtFlashSection.*)
*(.gnu.linkonce.r.*)
. = ALIGN(4);
} >OCTOSPI
What the code and linker additions above do is write the SVN version to the beginning of OSPI flash when the device is first programmed using the .hex file and programmer with external OSPI loader. The programmer I use is STM32CubeProgrammer or STM32CUbeIDE since they both support external OSPI loaders.
2021-06-18 02:08 PM
I found my own solution. I compare the binary size and crc of the GUI assets in OSPI flash and compare that to a locally downloaded file. It's a unique enough "version" identifier to fulfill my needs.
Edit: This doesn't actually work as well as I thought it would. The issue is that you can't prefill the CRC and size on first device boot because the application doesn't know how large the GUI asset binary is in OSPI.
A better solution that I found is to use TouchGFX Designer post-build steps to call SubWCRev.exe to generate a SVN version file with #defines that can be reference by the application. The application then contains the following:
const uint32_t m_gui_version __attribute__((section(".guiVersion"))) = SW_GUI_VERSION;
Where SW_GUI_VERSION is the #define with the SVN version generated by SubWCRev. Section .guiVersion is added in the linker at the beginning of OSPI as so:
/* GUI version - Make sure this is above ExtFlashSection */
.guiVersion ORIGIN(OCTOSPI) :
{
KEEP(*(.guiVersion)) /* Keep variable even if not referenced */
} >OCTOSPI
/* Constant data into "OCTOSPI" Memory Mapped Flash type memory (TouchGFX GUI generated assets) */
ExtFlashSection :
{
*(ExtFlashSection ExtFlashSection.*)
*(.gnu.linkonce.r.*)
. = ALIGN(4);
} >OCTOSPI
What the code and linker additions above do is write the SVN version to the beginning of OSPI flash when the device is first programmed using the .hex file and programmer with external OSPI loader. The programmer I use is STM32CubeProgrammer or STM32CUbeIDE since they both support external OSPI loaders.