STM32L4R9I-EVAL with DPI 480x272 LCD Application Template

[Pascal1]

Is there anywhere an Application Template available for this platform with the RGB TFT screen ?

Or any informations on how to do it, as it was asked here :

https://touchgfx.zendesk.com/hc/en-us/community/posts/360033454431-TouchGFX-support-for-STM32L4R9I-EVAL-board-with-480-272-LCD

Display is the same as on the F746G-Discovery so it should be easy to adapt template from the F7 board. But I'm not able to find the place where already available Application Templates are provided ? Is it possible to get the well-formed archive somewhere locally when connecting to the remote server ?

Ideally, this Application Template should generate an ioc file to STM32CubeMX, same as with the F7 board. With this file, we can then adapt the project to build with TrueStudio and/or SW4STM32 (done sucessfully on the F746 with some manual changes)

[Martin KJELDSEN]

Just to let you know, this is not an official project. It's based on a not-yet-released version of TouchGFX and as such will not work for you, but you can get some inspiration for how to configure the LCD.

[Pascal1]

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.

[Martin KJELDSEN]

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

[Pascal1]

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 ?

[Pascal1]

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

[Nilesh Badodekar]

Hi Pascal,

I apologize for budging in to this thread.

I am trying to do something similar on the STM32L4R9 Eval board with 1315 Display board.

Is it a good approach to start from 746G template from TouchGfX and then modify it for L4R9?

My eventual intention is to figure out if I can have the LCD buffer placed on the HyperRAM device or if that is possible at all.

Regards

Nilesh

[Pascal1]

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...

[Pascal1]

I think it's better to start from project provided in this thread by Martin, as it's already ready for L4 and not F7. If you want to use the MB1315 display board provided with the eval kit, modifications related to screen timings are already done in these files.

Of course you can finally have the framebuffer placed on HyperRAM but I would advice you to test first with the simpler configuration, i.e. framebuffer in internal RAM.

But Martin is the one wich can confirm or not that.

[Pascal1]

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 ?