Hello everyone
I recently bought an STM32H735G-DK Discovery Kit, which has a 480x272 parallel LCD. I got the TouchGFX Demo projects running on the board, so I know all the hardware is working as it should.
Eventually I want to use TouchGFX on a custom board, so I am trying to configure a new project 'from scratch'. I am very new to the STM32 ecosystem, so I thought I would keep things simple and try to display something on the LCD with a framebuffer in the internal RAM.
So I started a new project in the STM32CubeIDE, from an existing ioc file (the one from one of the TouchGFX examples). I then disabled OCTOSPI1, OCTOSPI2, FREERTOS, LIBJPEG, TOUCHGFX, CRC, in order to have a project which is as bare bones as possible.
Following this guide (https://support.touchgfx.com/docs/development/board-bring-up/how-to/02-cpu-running), i was able to access the internal RAM (with some trial and error, I found I could address bytes 0x08000000to 0x08100000.
I then continued to this guide (https://support.touchgfx.com/docs/development/board-bring-up/how-to/03-display-internal). I was able to see the LTDC interrupt working by utilizing break points in the debugger. I started with a partial framebuffer of 480x100. This way I am sure that it fits in the internal RAM.
However, I was not able to get a red screen, as I would expect following the tutorial. My screen stays black. I am unsure what I am doing wrong. I am also unsure what I should put in the 'Color Frame Buffer Start Address', since it seems I should declare the framebuffer myself? I feel like I am missing something, but I don't know what or where to look.
I hope you can help me get past this 'issue'.
Kind regards
Anton
Hello @hanton ,
I can see it's your first post in our forum. Welcome to the community 😀
It's an excellent idea to start with the board bring-up as you do. You'll for sure learn from it!
I briefly looked at your project and from the symptom you mentioned, I guess it could be due to some of the priority in here :
The lower the number of the "Preemption priority" is, the higher is the priority.
If it's not this, you can try to run your program on your board, and use STM32CubeProgrammer to see it there's the data you expect in the memory range of your framebuffer. If there's no data, the HAL_LTDC_LineEventCallback() is probably never called.
