Optimisation options and screen tearing

Question

Hi.

I built a custom board using an STM32H7 and ported the embedded wizard.

In development, it works fine and displays the screen.

In the final step, I set the optimisation option in the STM32 compiler to "Optimise for speed (-Ofast)" and write the firmware binary file to the board and check, the characters are broken.

 

Firmware with no optimisation options set will work normally.

Images and such are fine, but only text is broken.

 

I am in a situation where I need an optimisation option due to performance issues, do you have any ideas to solve this?

 

Answer 1

Hello,

due to the fact that many characters are printed twice, it seems to be more a compiler issue. What compiler and which version are you using? Did you try other compiler optimization levels?

The title mentions screen tearing - how is this issue related to tearing? Btw: What Embedded Wizard version are you using, which color format is used and how is your display connected to the STM32H7?

Best regards,

Manfred

Comments

Hi.

Sorry. I must have explained it wrong. It's more accurate to say that the characters are broken than torn.

 

My build environment looks like this.

- Embedded wizard 11
- STM32CubeIDE 1.16.0 and STM32Cube_FW_H7_V1.11.2 package
- Toolchain : GNU Tools for STM32 (12.3.rel1)
- Language standard : GNU18 (ISO C18 + gnu extensions)
- Optimazation level : -Ofast (Optimize for speed)
- MCU : STM32H753XI
- Display : 7-inch LCD 1024 x 600
- Color depth : RGB565
- using LTDC and DMA2D
- using I-Cache and D-Cache



I have attached a picture of the difference when changing only the Optimisation option in the same environment.
On the left, the optimisation option is not set (-O0) and on the right, the optimisation option is set to (-Ofast).

I tested other optimisation options and found the same issue with -O3.
-O0, -O1, -O2 and -Os, -Oz are fine.

---

Hello,

thanks for the additional information. In case of GCC (which is used inside the STM32CubeIDE) it is difficult to report the compiler manufacturer an issue. We observed (years ago) several issues with highest optimization, where the optimized code is not working properly even though the C code was legal. We choose -O2 as the best solution and provide our libraries and examples with this option.

Is -O2 a solution for your project? Otherwise, you can try to find the module that is not working properly with -O3 and just compile this one with a lower optimization level. Maybe this is a solution that works for you.

Best regards,

Manfred.