cancel
Showing results for 
Search instead for 
Did you mean: 

Inconsistent use of TEXT_LOCATION_FLASH_ATTRIBUTE breaks OTA asset binary sharing

grisa199678
Associate II

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.

 

Problem:

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.

 

Inconsistency in Code Generation:

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.

 

 

Proposed Fix:

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

Target Setup:

  • MCU: STM32F769NIHx

  • Board: STM32F769I-DISCO

  • TouchGFX Version: 4.24.2

  • External Flash: 64MB QSPI

  • Asset Sections Used: ExtFlashSection, FontFlashSection, TextFlashSection

1 ACCEPTED SOLUTION

Accepted Solutions

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

 

 

View solution in original post

4 REPLIES 4

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

 

 

Hello Flemming,
 
Will apply the temporary solution described.
Looking forward for the next version to be released and migrate to it.
 
Thank you for the patience and feedback.
 
Wish you a great week and holidays.

Grigore

 

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

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.