TouchGFX and CubeIDE... External Memory Issue

[JLojo]

On a STM32U5G9J-DK2 kit, once a project, created within TouchGFX, is imported to CubeIDE bitmap images are lost when placed in the external flash memory.

TouchGFX version is 4.23.0, CubeIDE is 1.14.1 and everything is installed on a Windows 10 machine.

Right after the project is created under TouchGFX, it loads correctly to the kit and all images are there.

As soon as it is imported to CubeIDE, regenerated and compiled, it loads to the  kit, everything works perfectly... except bitmap images loaded to the external flash (shapes and other graphics loads perfectly though). Images do not show up, and instead there are parts of the previous display at the place of the bitmap. If bitmaps are set to be stored on internal flash in TouchGFX and the project recompiled under CubeIDE, then all images come again on screen.

I thus double (actually much more than double) checked everything I could suspect: external flash loader, flash.ld files... but did not see any differences between the files generated at first loading from TouchGFX and the ones generated under CubeIDE.

I may be missing something obvious, but  no way to figure out what!!!

Any guidance?

jylo

Thanks

[Tesla DeLorean]

You'd perhaps want to unpack the .MAP and .ELF files to understand what was built.

You can use STM32 Cube Programmer and the appropriate External Loader to upload and verify the .ELF gets delivered properly.

Get some checksums and hashing working so you can confirm content as built.

[JLojo]

Many thanks Tesla DeLorean for your prompt advice.

Actually I checked everything I could: the content of the flash looks good to me; at least it is exactly similar to the content of image_alternate_theme_images_previews_preview12.o generated by TouchGFX.

To me it doesn't look very well optimized for storage size, but anyway, this is what it is, and checking the same file, generated with 'Internal Memory' selected, provides the exact same structure.

Map file says it will place at the expected location:

ExtFlashSection
                0x00000000a0000000   0x1e7800
 *(ExtFlashSection ExtFlashSection.*)
 ExtFlashSection
                0x00000000a0000000    0x38400 ./Application/User/generated/image_alternate_theme_images_previews_preview12.o
                0x00000000a0000000                image_alternate_theme_images_previews_preview12
 ExtFlashSection
                0x00000000a0038400    0x38400 ./Application/User/generated/image_alternate_theme_images_previews_preview15.o
                0x00000000a0038400                image_alternate_theme_images_previews_preview15
 ExtFlashSection
                0x00000000a0070800   0x177000 ./Application/User/generated/image_alternate_theme_images_previews_preview5.o
                0x00000000a0070800                image_alternate_theme_images_previews_preview5
 *(.gnu.linkonce.r.*)
                0x00000000a01e7800                . = ALIGN (0x4)

And this is what I can find reading back the external flash memory.

For any weird reasons, I've the feeling that this is more related to how TouchGFX read back the saved images.
Unfortunately I've had no time to further study how this is practically done because I'm getting late on my project.

So far, I will work with internal memory (and small bitmaps... :frowning_face:), still expecting to understand what is wrong here for the future of my project(s)...

JyLo
PS: to illustrate why I consider the storage not very well optimized, I also attach a dump of the .o file holding one of the images... lots of 0x00, maybe not so useful...

[JLojo]

Thinking I may have done something wrong during the process, or maybe some bugs were corrected on TouchGFX V23.1, I decided to remove TouchGFX V23.0, and start again from scratch.

So, I installed a fresh TouchGFX V23.1 on my computer.

Since this release still does not show up in CubeIDE, I import it 'from local' using x-cube-touchgfx-4-23-1.zip.

I then created a basic project under TouchGFX, in a specific folder to be able to create a CubeIDE workspace specific to that project (This is really a pain, that TouchGFX names the project with the board name instead of the project name, preventing to build several projects on the same board in the same workspace!)

I Compiled the project, loaded it onto the board fro mTouchGFX and every thing was OK.

I then imported the project under CubeIDE in a freshly created workspace .

I Compiled the project, loaded it onto the board and every thing was OK.

I finally edited STM32U5G9J-DK2.ioc (sadly named like that) added a timer, with half a second period, NVIC enabled, and in main.c, just toggle the green LED once HAL_TIM_PeriodElapsedCallback is trigged.

=> All bitmaps on the display got corrupted!!!

I went back to TouchGFX, compiled and loaded the project onto the board: same issue!

I switched 'Default Image Configuration'/Section to IntFlashSection and all images came back on screen, LED toggling!

TouchGFX seems to be a very powerful tool, but if it only consists doing a nice demo on a demo board, it is quiet useless! I definitely ask TouchGFX team to consider a better integration of TouchGFX in the official environment of ST Microelecronics, namely CubeIDE!

I finally tried to tackle the problem from the other end, as suggested in some posts, since I don't just want to run a demo!

That is, creating a blank project from CubeIDE, choosing STM32U5G9J-DK2 from board selector.

I got 2 errors when enabling TouchGFX in CubeMX: CRC IP not enable and Width/height not match Window size in LTDC.

First issue is easy to solve: simply enable CRC.

But I'm still struggling to solve the LTDC issue!

Is it possible to know what needs to be done to be able to generate code once IOC file generated?

Thanks

Jylo

[GaetanGodart]

Hello @JLojo ,

I did not follow the beginning of this thread.

Have you been able to solve your problem since then?

---

Is it possible to know what needs to be done to be able to generate code once IOC file generated?

---

If you have generated code using STM32CubeMX, You can freely code inside the designated area marked with 

/* User code starts here */


/* User code ends here */

Then, if you want to modify the ioc file (for instance add a gpio input), you can simply go back to STM32CubeMX, enable / disable whatever you need, generate code again and STM32CubeMX will modify your c and h files without touching what was in the user code section.

Also, your issue seems to be about STM32CubeIDE.
Have you tried simply using TouchGFX Designer to make your UI, modifying your c(++) and h(pp) files with a regular text editor (VSCode, SublimText, notepad:skull:, vim:skull::skull:) and then flashing your board directly from TouchGFX Designer?

(Note that you can still debug by using Visual Studio).

Regards,

[JLojo]

Hi Gaetan,

The issue is still here, but I think I was just able to identify the origin (today: what a coincidence!!!) .

The problem seems to be very simple:

If 'Generate peripheral initialization as a pair of '.c/.h' files per peripheral'  is checked under CubeMX, STM32 fails to load images from external flash!

And the project is definitely corrupted, with no way to recover it, even if you revert your choice.

Only options: use internal flash or recreate the project from scratch!

This is a pity because I was used to activate this option for years, since it allows to have easier to read source code and all my personal libraries refer to this architecture...

Best regards

JyLo

[GaetanGodart]

Glad you were able to fix your issue.

It is not the first time I see "Generate peripheral initialization as a pair of '.c/.h' files per peripheral" being the issue (not just for TouchGFX projects). The solution for people having this issue was just to disable the option even though it is great for readability or modifications.

Can you check a few things though?

1) What is written on the sticker with the board name on it?

2) How do you "import" your project to CubeIDE? The usual way of doing it is, after creating your project from TouchGFX Designer, go to the project files, open the folder "STM32CubeIDE", double click on the project, that's all.

3) Also, what is your TBS version (when creating the project)?

Regards,

[JLojo]

Hi Gaetan,

Many thanks for your feedback.

1) Sticker shows: STM32U5GNJ-DK2 / DK32U5G9J2$AR1

2) I've tried so many way to import (still regretting it is not more straight forward!)... Last one, as suggested by ST support team, was to open the .ioc with CubeMX (standalone version, not the one embedded in CubeIDE), do a generate; then create an empty workspace (because of this weird naming convention from TouchGFX!) and import the project from there.

3) TouchGFX is 23.2; CubeMX is 6.11.1 and I'm prompted to migrate from 6.11.0 to 6.11.1 after the first generation by TouchGFX... (I tried both: Migrate or Continue, with the same effect!)

Best regards

Jean-Yves

[GaetanGodart]

1)
STM32U5GNJ-DK2 / DK32U5G9J2$AR1 ?
Don't you mean
STM32U5G9J-DK2 / DK32U5G9J2$AR1 ?

2)
I still don't understand what you mean by importing. The way we do it here at TouchGFX is not importing but simply opening.
Create your project from TouchGFX Designer :

Create you GUI.
Generate code from Designer :

Open your projects file location :

Go back one folder :

Open the STM32CubeIDE folder :

Open your project :

No importing needed, no re-generating needed.

[JLojo]

Hi again,

1) Sorry for the typo. Yes indeed this is STM32U5G9J-DK2 / DK32U5G9J2$AR1

2) Doing as you suggest will anyway import the project in CubeIDE in the current workspace, leading to possible collisions (due to the identical name for all possible projects created under TouchGFX for the same kit).

This is why I open CubeIDE, select the Workspace I want, and then just import the project as a classical use of Eclipse. Otherwise I get the following message, which can be annoying...

When you do 'open' the project, Eclipse will 'import' it into the current workspace. Actually this is the wording of Eclipse.

If TouchGFX team would consider changing the way the projects are named by TouchGFX this will make our life much easier!!! ... and no questions anymore about opening or importing, or even creating a specific workspace for each application, etc...

best regards

Jean-Yves

PS.: The use of CubeMX was just suggested by ST Support Team, as a 'Must Do', but I'm still not convinced it is strictly necessary...