TouchGFX with SPI TFT

[ebray]

I've created a simple project to interface a STM32L4R91-DISCO with a TFT using a SPI interface. I've attempted to follow the TouchGFX tutorial but thus far have been unsuccessful in getting the TouchGFX library to render anything.

I have a task that sits in a loop, periodically calling OSWrappers::signalVSync(). This appears to work as the vsync_queue fills up. However, in my separate task which is running the ToughGFX loop, the call to OSWrappers::waitForVsync never returns. This mean the frames don't get rendered and flushed to the display.

Any suggestions for getting this running would be greatly appreciated!

I'm using STM32CubeIDE 1.3.1 with TouchGFX 4.13.0.

[Martin KJELDSEN]

Hi Ebray,

This is definitely an issue and i just created a branch to fix it - Until then, you need an update so you won't have to revert/fix it every time. I could send it to you, but you can actually fix it yourself temporarily.

Edit the following file - Search for "CMSIS V2" (This is not a problem for V1). Remove the call to `osSemaphoreAcquire(frame_buffer_sem, osWaitForever);`

C:\Users\eric\STM32Cube\Repository\Packs\STMicroelectronics\X-CUBE-TOUCHGFX\4.13.0\CubeMX\templates\Target\OSWrappers_cpp.ftl

 /Martin

[ebray]

Martin,

Thank you for pointing me to the template for the temporary fix. I'm able to get the modification to persist and Double Buffering now appears to work as expected.

Do you have any thoughts as to what could be causing the issue for the Single Buffer option? My display is 320x480 so unnecessarily using 2 frame buffers consumes over 90% of the RAM which is very restrictive to my application.

Thanks!

Eric

[Martin KJELDSEN]

Perfect :) Can we go over what the issue is for single buffering again? The vsync queue is filled up?

/Martin

[ebray]

Single buffering gets stuck in HAL::LockFrameBuffer. You mentioned there are only two function calls in there and they're only used in the single buffer case:

    dma.isDmaQueueEmpty();
    dma.getAllowed();

When I stop the debugger, it appears FreeRTOS is still operating normally (eg. no crashes or anything), but the call to HAL::LockFrameBuffer is permanently stuck in a loop. The disassembly below shows the relevant lines highlighted in green. These 3 lines just execute in a cycle repeatedly.

Thanks!

Eric

[ebray]

Have you had a chance to look into this issue with the single buffer implementation?

[Richard Lowe]

I can confirm that I have the same behavior. Works with double buffering but fails on unlocking buffer when single buffer is used. Can we get confirmation that this is a bug and if it is or isn't being looked at?

[VLau]

Same behavior here. Engine stucks with single buffering strategy option enabled in CubeMX. Only double buffering works.

HAL.hpp
 
virtual void backPorchExited()
{
     swapFrameBuffers();
     tick();   // <- here
}

[SMour.1]

I seem to have a very similar problem , even though a simple test like that works

//freeRtos thread 1
while(true)
{
    LL_GPIO_SetOutputPin(LFO1_LED_GPIO_Port,LFO1_LED_Pin) ;
    touchgfx::OSWrappers::signalVSync();
}
//freeRtos thread2
while (true)
{
    touchgfx::OSWrappers::waitForVSync();
    LL_GPIO_ResetOutputPin(LFO1_LED_GPIO_Port,LFO1_LED_Pin) ;
}

replacing the second thread with   

MX_TouchGFX_Process();

Seems to stuck before even calling

flushFrameBuffer

[Michael K]

@Martin KJELDSEN​ I'm having this exact problem as well, in 1.17. STM32L496G-DISCO, generated a project CubeIDE, got my display working with manual RAM writes, enabled TE, called OSWrappers::signalVSync from the EXTI callback for the TE line, added MX_TouchGFX_Process(); to the default task so the engine should be running. Not much else other than added a second task to blink an LED. Same symptoms as @ebray​ , other tasks run fine, and my code enters the same 3 instructions, and double buffering works fine.

[Alexandre RENOUX]

@Michael K​ @ebray​ @Richard Lowe​ @VLau​ @SMour.1​ 

Hello,

I see that the issue is reproduced by many and to investigate we need more information.

From what I understand (correct me if I'm wrong), it's a problem that happens with STM32L4 and could normally be reproduced with L4R9-DISCO or L496-DISCO.

Do you all use one of these 2 MCUs with DSI and Single buffering ? Does it also happen with other MCUs ?

Have you tried using the latest 4.18.1 TouchGFX version and checking if it is working or not ?

Could you provide the steps you did to reproduce the issue ?

Thank you very much for your help ~

/Alexandre