2025-04-17 12:54 AM - last edited on 2025-04-17 2:08 AM by Andrew Neil
We are implementing a software-driven OTA update system using TouchGFX and a 64MB external QSPI flash. We store the following asset sections in QSPI:
ExtFlashSection
FontFlashSection
TextFlashSection
These are bundled into an ExternalFlash.bin asset file, which should be shared between firmware partitions (A/B). Since the data contains only static assets, it must remain bank-independent for OTA to work properly.
In the generated TypedTextDatabase.cpp, the following array is incorrectly marked with TEXT_LOCATION_FLASH_ATTRIBUTE:
TEXT_LOCATION_FLASH_PRAGMA
const touchgfx::TypedText::TypedTextData* const typedTextDatabaseArray[] TEXT_LOCATION_FLASH_ATTRIBUTE = {
typedText_database_GB,
typedText_database_ESP
};
This array is placed into TextFlashSection, which is part of ExternalFlash.bin. However, the array contains pointers to other flash-resident data (typedText_database_GB, etc.), which are already placed correctly in TextFlashSection.
Storing the array itself in flash causes absolute addresses to be written into ExternalFlash.bin, which ties it to the current firmware bank — defeating OTA partition independence.
This issue appears to be a code generation oversight, because in other sections (e.g., ExtFlashSection, FontFlashSection), the generated arrays do not use TEXT_LOCATION_FLASH_ATTRIBUTE. For example:
const touchgfx::Font* const fontList[] = {
&font_roboto_16_4bpp,
&font_roboto_24_4bpp
};
These arrays are placed in RAM, and only reference data located in external flash — which is the correct and expected behavior.
So, it's clear this is not a design choice, but a developer inconsistency in how typedTextDatabaseArray is handled.
Remove the TEXT_LOCATION_FLASH_ATTRIBUTE (and pragma) from the array declaration in TypedTextDatabase.cpp:
const touchgfx::TypedText::TypedTextData* const typedTextDatabaseArray[] = {
typedText_database_GB,
typedText_database_ESP
};
With this fix:
The array is stored in RAM (in firmware partition A or B)
It references data in external flash (QSPI-mapped)
The asset binary remains bank-independent
MCU: STM32F769NIHx
Board: STM32F769I-DISCO
TouchGFX Version: 4.24.2
External Flash: 64MB QSPI
Asset Sections Used: ExtFlashSection, FontFlashSection, TextFlashSection
Solved! Go to Solution.
2025-04-23 11:40 PM
Hello Ciobanu
This makes sense. I will make a bug report on this for future versions.
You can fix this in your code if you want.
In the file: touchgfx/framework/tools/textconvert/Templates/TypedTextDatabase.cpp.temp
Either do this in your installation (c:/TouchGFX/4.24.x/ typically) or in the Middlewares/ST/TouchGFX folder in a specific project.
After the modification, delete the generated/texts folder and generate code again.
Another way is to modify the Makefile to remove the line (using perl or sed or a more modern tool) after each code generation or before compilation.
Best Regards
2025-04-23 11:40 PM
Hello Ciobanu
This makes sense. I will make a bug report on this for future versions.
You can fix this in your code if you want.
In the file: touchgfx/framework/tools/textconvert/Templates/TypedTextDatabase.cpp.temp
Either do this in your installation (c:/TouchGFX/4.24.x/ typically) or in the Middlewares/ST/TouchGFX folder in a specific project.
After the modification, delete the generated/texts folder and generate code again.
Another way is to modify the Makefile to remove the line (using perl or sed or a more modern tool) after each code generation or before compilation.
Best Regards
2025-04-24 1:05 AM - edited 2025-04-24 1:05 AM
2025-09-05 2:35 AM
Hello Ciubano.
We have merged this fix for next release (4.26). I don't have the release date.
I just wanted to ask you a question, since I don't fully understand your setup. Just to make sure we have all the details correct.
I understand that you use the two banks of internal flash to have A/B firmwares. And, as you say, the data in QSPI flash should be useable by both. For example, if you fix a small bug, not related to graphics, you just update the internal flash (B) and leave the external flash unchanged.
For this, I don't see why a pointer in external flash to external flash is a problem (I agree it should not be there).
Do you flash the external data to a different address than it was linked to?
Do the A/B firmwares use different flash addresses, and then you just copy from flash-to-flash?
Please describe the situation where the typedTextDatabaseArray addresses are wrong.
Best Regards
2025-09-05 5:10 AM
Hello Flemming,
On my setup, between internal flash A/B are no differences except which are the assets addresses in external flash.
Also external flash data is compatible with both firmware stored in internal A/B.
For example, if I use same for firmware A will be used from 0x90000000, for B -> 0x91000000.
From bootloader, if I start firmware A, it will use assets from 0x90000000(with texts from there).
If I start firmware B, it will use assets from 0x91000000, but the Text Section pointers will be dependent of linkers used for compilation.
In case of a OTA the secondary bank will be erased, typedTextDatabaseArray from primary bank can point to data from secondary unused bank(because of bug), so when erasing that part, the devices crashes and never start because the touchgfx cannot load texts, which exists on primary bank but typedTextDatabaseArray points to inactive bank.
By removing the pragma, at linking, that variable will be placed in InternalData.bin not ExternalData.bin.