Graphics glitches on STM32F429I-DISCO

[Damien Ratazy]

Hello,

I'm trying to setup a simple example on my STM32F429I-discovery board, but i'm experiencing issues with some graphics (images).

I had setup CubeMX using this guide : https://touchgfx.zendesk.com/hc/en-us/articles/360021620431-Configuring-STM32F429I-DISCO

As you can see on the picture above, the text is displayed fine, but the background image and the button are corrupted. However, LCD seems to work properly, because the text is correctly rendered.

I'm using EWARM 8.22.2 and the lastest versions of TouchGFX and CubeMX. The project compiles fine.

[Martin KJELDSEN]

Could you check your map file and check where that image is placed by the linker? And

then check that memory to see that flash has been programmed correctly?

Did you get any warnings when flashing?

/Martin

[Damien Ratazy]

Here a copy of a portion of my .map file :

*******************************************************************************

*** PLACEMENT SUMMARY

***

"A0": place at 0x08000000 { ro section .intvec };

"P1": place in [from 0x08000000 to 0x081fffff] { ro };

define block CSTACK with size = 1K, alignment = 8 { };

define block HEAP with size = 512, alignment = 8 { };

"P2": place in [from 0x20000000 to 0x2002ffff] {

     rw, block CSTACK, block HEAP };

initialize by copy { rw };

 Section        Kind    Address   Size Object

 -------        ----    -------   ---- ------

"A0":                      0x1ac

 .intvec        ro code 0x08000000  0x1ac startup_stm32f429xx.o [1]

                - 0x080001ac  0x1ac

"P1":                     0x453a2

 ExtFlashSection    const  0x080001ac 0x25800 Dark_Backgrounds_main_bg_portrait_texture_240x320px.o [1]

 ExtFlashSection    const  0x080259ac  0x9f60 Blue_Buttons_Round_Edge_small.o [1]

 ExtFlashSection    const  0x0802f90c  0x9f60 Blue_Buttons_Round_Edge_small_pressed.o [1]

 .text         ro code 0x0803986c  0x12c8 LCD16bpp.o [8]

 .text         ro code 0x0803ab34  0x3b8 Bitmap.o [8]

 .text         ro code 0x0803aeec   0xa6 ABImemcpy.o [6]

 .text         ro code 0x0803af92   0x4e AbstractButton.o [8]

 .text         ro code 0x0803afe0   0xb4 DisplayTransformation.o [8]

 .text         ro code 0x0803b094  0x6ac HAL.o [8]

 .text         ro code 0x0803b740  0x8ba LCD.o [8]

 .text         ro code 0x0803bffa   0x10 Screen1ViewBase.o [1]

 .text         ro code 0x0803c00a   0x1a FrontendApplicationBase.o [1]

 .text         ro code 0x0803c024   0xf0 OSWrappers.o [1]

 .text         ro code 0x0803c114   0x8 touchgfx_gpio.o [1]

 .text         ro code 0x0803c11c  0x760 Application.o [8]

[...]

I tried to verify the checksum of the flash, do a full chip erase, and re-program the flash, and i still get the exact same issue.

I didn't get any warning or error while flashing.

[HP_it]

this does look familiar when the program assumes that the assets are located in external memory but they aren't loaded properly. How do you load the external flash?

[Martin KJELDSEN]

There's no definition for the ExtFlashSection (Generated by the image converter in TouchGFX) so the linker defaults to internal memory. I don't really see why they wouldn't be loaded. I'll have to think about it.

/Martin

[HP_it]

but there is a reference to the ExtFlashSection for the assets - or is the hex value the starting address? I'm not familiar with the .map files

What triggered me was the remnants of the button - you can almost see the outline of the button which means that there could be some residue data from another process. For example if one was testing with the designer first (and it worked) and then tried uploading the code from CubeIDE where no external loader was present.

[Damien Ratazy]

I tried to put all the assets in the "IntFlashSection" (TouchGFX designer parameters), and I got the same issue.

The STM32F429I-DISCO board doesn't have any external flash chip (only the MCU+SDRAM).

[Martin KJELDSEN]

It doesn't, but if the ExtFlashSection isn't defined in your linkerscript anyway you can see that it's already using internal flash. The imageconverter just always outputs the ExtFlashSection pragma so that the user can define it in his or her linker script

/Martin

[Martin KJELDSEN]

You could try creating a completely RED image and then checking the address of the linker script to see if you can read RED from the memory. I can't imagine that the flash has been programmed properly with the images.

/Martin

[Damien Ratazy]

I tried this example :

https://s3.amazonaws.com/axxonshare/my_combo_tutorial.zip

And somehow, it worked for me... but I'm unable to explain why, the project seems configured exactly as mine (the linker aswell).