STM32L4R9I-EVAL with DPI 480x272 LCD Application Template

There are examples under the HAL trees which bring up the screen and other peripherals. Those can be used as donor projects that can be cloned.

​

There should be better templates, and a prime example of where automated tools should be able to assemble usable boilerplate code.

I thought CubeMX had some maximal output modes by selecting the EVAL or DISCO boards as targets.​

Hi. Maybe this will help,

a) launch the TouchGFX 4.10.0 tool as a stand alone

b) select the F746G-Discovery target

c) Select the v2.0.0 template

d) proceed to create some simple gui -> Generate code -> test with simulator

e) if the above works, review the source code -> lower right corner of the TouchGFX tool will allow for the viewing of the generated code folders

You should be able to view the TouchGFX v2.0.0 generated template here. It is in ASCII format.

Hope this helps.

I have an unofficial STM32L4R9-DISCO project with the 480x272 LCD you can get some inspiratipon from if it's of any interest.

Sure ! I would greatly appreciate this projet as a starting​ point, even if it's unofficial. Thanks for your help.

Was busy on other issues and just came back on this point a few days ago.

My starting point was a CubeMX generated project where I did all manual modifications to get a c++ compiling project, linking with touchgfx lib. Everything under Truestudio. Inspiration comes from your sample project and also from working project for F7 series.

Some progress but still not a running application.

My LCD needs some SPI configuration before working in DPI mode (320x480 16BPP). This low level part of init is done before starting touchgfx.

I can check LTDC is correctly configured because I'm able to perfectly display a picture at this step.

As every low level is done before, "hw_init()" is empty.

I'm in the most simple configuration : only one framebuffer in internal memory (an octospi RAM is present and planned for use in the future).

With TouchGFX Designer I created a simple GUI with just a button and color background. I then manually copy the generated files in my project.

When I start the GUITask, I'm able to display the correct GUI but it crashed just after. I'm landing on the HardFault handler but i'm not able to identify the place where it comes from.

I'm running on FreeRTOS, and other tasks are running well when not starting GUITask. I disabled every other task but the GUI Task so I'm sure the problem is not related to another task.

I tried to increase stack size for the GUI task, no change.

I tried to increase the full heap size available, no change.

I disabled touchscreen support, no change.

I disabled DMA support and ChromART support, no change.

I checked interrupt priorities, especially on LTDC and DMA2D, looks good.

In fact I'm able to pass 2 or 3 times in Model::tick() before crashing. I'm not able to debug the problem as it happens during lib object execution.

I tried to use Tracealyzer to trace the problem but looks like this tool is not happy with the c++ flavour of the project so I can't use it with touchgfx.

Any idea how I can identify the problem and solve it ? How can I get more details during touchgfx part execution ? MCUInstrumentation or kind of gpio output to trace execution could be usefull ?

Thanks in advance for your help.

Hi Pascal,

We've intstrumented the code to call GPIO methods - These are mostly for performance measurements. MCU instrumentation is to measure the MCU load.

Have you tried following the execution manually (after 2 ticks) to see where you end up? Yea that's a bit tedious. When you're in HardFault handler, what does TrueSTUDIO tell you about the stack pointer? In IAR 8 it will tell you things about what was executed right before the HF.

/Martin

In fact, landing on HardFault handler is just an artefact of something which looks like a stack corruption. No Hard Fault is really happening so no investigation on stack pointer is really usefull.

By spying the content of pxCurrentTCB (pointing on GUI Task, the only one created with idle) during execution I can check everything is good up the point the screen is displayed (correctly) by TouchGFX. BUT, just after this content becomes dummy (during blinded execution of some code of the touchgfx lib). When I breakpoint on the backPorchExited() function I'm able to reproduce the problem on the step just after a first one full display.

What I find quiet strange is that if the problem is related to the stack memory , I should notice a change (crash after some steps more) when I notably increase its size. That's not the case ?...

Rest of my code is quiet similar to what you provided in your project, only some adjustments on DPI screen of course.

Any clues ?

After crashing all memory (FR tasks stack as well as framebuffer) is filled with the same pattern 0x17 0x4D. Looks familiar ?

Just tried also to not start FreeRTOS and run TouchGFX with a busy loop. After changing content of OSWrappers.cpp conformed to https://touchgfx.zendesk.com/hc/en-us/articles/204887741-Running-TouchGFX-without-an-operating-system and staying in the same configuration, i can notice the same problem, so it looks like not specifically FR related.

 I got the same behavior : after one correct refresh of the screen, it crashes during touchgfx::Drawable::getCachedVisibleRect(). But I suppose this is just a question of timing and not directly related to this function.

Anyway, as no RTOS is running, I can exclude a problem of FR stacks corruption with task's commutation.

Anything specific about memory allocation done in the pre-compiled part ? Or a bad pointer due to something not correctly initialized ?

Is there some flags or configuration about libc, syscalls or things like that to compile with against your lib which can impact the correct execution.

It's quiet strange and have no other idea to debug it...

Still doing some investigations.

Even if I said the contrary in one of my previous post, looks like I really get an hard fault... When I look at SCB->CFSR, PRECISERR and BFARVALID are 1.

BFAR is 0x4D174D23 (which is the pattern I noticed on memory previously)

So do you have something in mind in touchgfx related to this kind of error ?