TouchGFX tick not running (methods not mutated)

[CommanderCloud]

Hello!

 

First, some information: I am running a custom board with an STM32U599VJT6 and a 480x480 RGB666 screen. I am running single frame buffer, by allocation. All other settings are like the STM32U5A9-DK discovery board uses (as far as I know).

The problem: the handleTickEvent function is not running, model tick is only running once (I checked with breakpoints). The initial framebuffer does get generated and displayed successfully on the screen but I cannot update the screen after that. The LTDC interrupt fires at a correct 16ms interval. So far, the debugging has led me to find that it seems that some functions related to the VSYNC in HAL_LTDC_LineEventCallback in TouchGFXGeneratedHAL.cpp are not mutated (defined as virtual functions but not overwritten). (See pictures).

(Eclipse code highlighting says that the bold text is mutated, the normal text is virtual.)

 

I cannot find where the mutation is supposed to happen. This is the only significant difference I have been able to find between the code I'm working on and the demo code.

 

Also, I needed to manually add TouchGFXHAL::setFrameBufferStartAddresses with associated functions before it showed anything at all, which is not documented as far as I know. Should I put that in a separate forum post?

 

 

Kind regards, Cloud

[Mohammad MORADI ESFAHANIASL]

Hello @CommanderCloud ,

I am surprised that HAL::swapFrameBuffers() is set as mutated because it shouldn't be and it is just a function defined in HAL.hpp. 
About your second question, you are absolutely right. Unfortunately, there is no note that the addresses should be passed to the LTDC as well. We will definitely update the documentation.

Anyway, you need to make sure that your application receives the tick from the Application Tick Source. In other words, HAL::tick() should be called every frame. So, it's better to focus on that and follow the trail of calls that will end up in calling HAL::tick(), which is from backPorchExited() that is called after OSWrappers::waitForVSync(). Please refer to this document to read about waitForVSync() and signalVSync(). 

I hope this helps you, don't hesitate to ask more questions!

[CommanderCloud]

Hello,

 

I think I identified the problem, and now the handleTickEvent is running, but much too slowly. In the HAL_LTDC_LineEventCallback function in TouchGFXGeneratedHAL.cpp, there was an if else statement with the conditional LTDC->LIPCR == lcd_int_active_line. This was true only once, so the OSWrappers::signalVSync() was called only once. I removed the conditional so the signalVSync() is called every LTDC interrupt and then it ran. I still don't know why it was called only once, which seems to be the crux of the problem.

A picture of the modified code is below.

 

This is not a solution. If anyone knows why LTDC->LIPCR is not equal to lcd_int_porch_line, please let me know.

 

Kind regards, Cloud

 

[CommanderCloud]

Hello,

 

I solved the problem. I found where LTDC->LIPCR was being changed from lcd_int_active_line to zero. In the stm32u5xx_it.c, in the LTDC_IRQHandler, the function HAL_LTDC_ProgramLineEvent was being called. I removed that, and now the conditional is being met. The tick is up and running at the correct speed. The reason the tick was running too slow is also solved, and it was because I had a blocking function in the model.tick() method that took too long. (osMessageQueueGet).

 

Kind regards, Cloud.

[jchernus-fikst]

Thanks for sharing this solution - it just resolved two weeks of me trying to chase down this same bug.

I wonder why the tutorial suggests adding that line if it breaks some people's projects, and how a future user could determine if they fall into this category. I wonder if someone from ST has any insight.

Thanks again, friend!