STM32F4 (using GCC) lvgl fails when optimisation turned on

Description

lvgl fails to run when code optimisation turned on
I’m running a minimal application than does nothing but display “Hello, World”
The code intialises the LCD SPI interface, but none of the video buffer flushing ever gets called - so prob not my stuff!.

What MCU/Processor/Board and compiler are you using?

STM32F407
GCC ARM Embedded Toolchain 9-2020-q2-update
ST7735 LCD SPI

What do you experience?

Everything works fine with the optimisation turned off. When I turn on code optimisation (any level) then the application fails to display anything - application loops wating disp_drv->buffer->flushing, but this because memory is trashed and not related to the cause - just a symptom i think.
Obviously debugging is hard when optimisation in on, but one of the first noticeable symptoms is the value of dispBuf.buf2 changing (ie it now points to some random region of memory).
There are other bit of memory changing that shouldnt, so memory is being trashed by something.
I’m trying no nail it down by turning on bits of optimisation and re re run it.
But if anyone else has seen this let me know.

What do you expect?

It to work!

Code to reproduce

Will update if I get close.

Screenshot and/or video

Since you’re using STM32, I think the debugger will support watchpoints. You could try setting a watchpoint on that variable to find out what is changing it.

Just been doing exactly that and I found the error just as your email arrived.
And I made the most fundimental schoolboy error - the Stack. - Do I feel dumb!
While the freeRTOS stack is way big enough for the main GUI loop, I was performing the lcd/lvgl in main(), which has next to no stack (by design). Why it ever worked (with no optimisation) i’ll never know.

Thanks for the very quick response.

And now I have a (working) port for the STM32F4 using SPI and DMA for the ST7735 driver - happy to share if someone wants it.
I’ve had a working port of V5.4 for a while now, and thought it was time to upgrade.

thanks
Mark