cancel
Showing results for 
Search instead for 
Did you mean: 

Solved: Weird flash when updating first quarter of screen

marittia
Associate II

Hello everybody,

I'm currently using CubeMX + Touchgfx with my Stm32f469i-disco board.

Everything works fine, but whenever the board needs to update something that is one first quarter of the screen (e.g updating a text) the whole quarter of the screen reblinks. This doesn't happen when i'm updating something that is otherwhere on the screen.

The only strange thing I did was setting manually the hltdc.Init.AccumulatedActiveW and TotalWidth to 202 and 203 (instead of the 802 and 803 created by CubeMX), otherwise the lcd doesn't work properly.

Thanks,

Mariano

1 ACCEPTED SOLUTION

Accepted Solutions
marittia
Associate II

Hello everybody,

I solved my issue, all I did was creating from scratch a new CubeMX project following this guide:

​https://touchgfx.zendesk.com/hc/en-us/articles/360020208091-Configuring-STM32F769I-DISCO

Which is for the 769i-disco but works fine with my 469i-disco. Now there's no sign of flickering and all of this without the double buffering.

Extra tips: in CubeMX set the Active Width to 800, then in the HW_Init.cpp file change ​hltdc.Init.AccumulatedActiveW and TotalWidth to 202 and 203 (I think CubeMX doesn't divide the Active Width by 4 automatically).

Thanks to everyone who helped me figuring out what the problem was, I think it has something to do with the DSI as @Martin KJELDSEN​ suggested.

View solution in original post

9 REPLIES 9
Franco77
Associate II

Which development platform do you use? TrueStudio, AC6, or something else?

TrueSTUDIO. The weirdeness appears like it renders a white rectangle for a moment.

marittia
Associate II

Now I enabled the double buffering and there is no more flickers, however, during some animations in screen changes the board stucks into WWDG_IRQHandler.

The only change I did was setting hal.setFrameBufferStartAddress((uint16_t*)frameBuf0, bitdepth, true, true); into BoardConfiguration.cpp

Martin KJELDSEN
Chief III

Hi @marittia​,

It would be nice to get to the bottom of this. Enabling double buffering the DSI based boards should not be necessary. How did you create this project? Through TouchGFX designer or CubeMX?

/Martin

marittia
Associate II

Thanks for your help!

I created the project using CubeMX, I only Executed TouchGfx via CubeMx​

Okay, there are issues with the DSI configuration created by CubeMX.

Could you please try creating the application through the designer using the stm32f469i-disco Application template? I'm pretty sure you won't have those issues then.

/Martin

Is there maybe some interrupt the DSI is generating during double buffering for which I may have not defined the relative handler? I had a very similar issue with the CAN bus and it happened because I didn't defined the interrupt handlers in the stm32xx_it.h/c​.

And isn't there any example on how the DSI must be setted for the 469i-disco? I just used the default configuration, maybe there's something that needs to be changed.

Thanks again for your time,

Mariano​

@marittia​, There's no specific guide for that. Single or double buffering has no impact, handler-wise. It's an internal touchgfx thing, driven by the TE signal.

If you use the Application template for F469-DISCO through the designer you can find the right DSI configuration. CubeMX does not generate the right one.

/Martin

marittia
Associate II

Hello everybody,

I solved my issue, all I did was creating from scratch a new CubeMX project following this guide:

​https://touchgfx.zendesk.com/hc/en-us/articles/360020208091-Configuring-STM32F769I-DISCO

Which is for the 769i-disco but works fine with my 469i-disco. Now there's no sign of flickering and all of this without the double buffering.

Extra tips: in CubeMX set the Active Width to 800, then in the HW_Init.cpp file change ​hltdc.Init.AccumulatedActiveW and TotalWidth to 202 and 203 (I think CubeMX doesn't divide the Active Width by 4 automatically).

Thanks to everyone who helped me figuring out what the problem was, I think it has something to do with the DSI as @Martin KJELDSEN​ suggested.