Screen tearing problem on STM32F769I-EVAL

Question

I have UI running on STM32F769I-EVAL with SMX RTOS and using IAR EWARM, DMA2D with interrupt on, double buffer on.

However, it seems to suffer from tearing effect with screen refresh, i do a simple test to change screen background colour with each tap.

The code provided has this.

/*******************************************************************************
* FUNCTION:
*   EwBspSetFramebufferAddress
*
* DESCRIPTION:
*   The function EwBspSetFramebufferAddress is called from the Graphics Engine
*   in order to change the currently active framebuffer address. If the display
*   is running in a double-buffering mode, the function is called after each
*   screen update.
*   Changing the framebuffer address should be synchronized with V-sync.
*   In case of double-buffering, the function has to wait and return after
*   the V-sync was detected.
*
* ARGUMENTS:
*   aAddress - New address of the framebuffer to be shown on the display.
*
* RETURN VALUE:
*   None
*
*******************************************************************************/
void EwBspSetFramebufferAddress( unsigned long aAddress )
{
  CurrentFramebufferAddress = (uint32_t)aAddress;
}

Q: Is there some code missing here to deal with VSYNC?

Answer 1

Hello,

in case of STM32F769 Evalboard, which has a display connected via DSI, there are interrupts from DSI and LTDC used in order to make a tearing free display update.

Please have a look into the file ew_bsp_display.c within the folder /TargetSpecific, there you will find an implementation that works for bare metal and for FreeRTOS operating system. If you are using a different OS, please try to adapt this part accordingly.

Additionally, the interrupts for DSI and LTDC have to be enabled.

Best regards,

Manfred.

Comments

Morning Manfred,

Let me provide a little more background on where my EmWi project integration is at.

I have seen the TargetSpecific FreeRTOS macros and made equivalent changes suited to our SMX RTOS in ew_bsp_display.c, ew_bsp_event.c, ew_bsp_graphics.c and ew_bsp_system.c. I have also split up the sample main into low level system init called before SMX RTOS is started then start a task for EmWiMainLoop later on. The SMX RTOS takes care of the system tick, RTC and serial setup so I only call EwBspConfigSystem from __low_level_init which IAR invokes before main. It was needed to avoid some of the MPU/SDRAM init since our project code and data is running from SDRAM rather than ROM. In RTE I make changes to direct EwAlloc and EwFree to the SMX heap and EwPrint to the SMX console routines.

When debugging with IAR EWARM I can see that both the DMA2D and the DSI interrupts are operational and the SMX RTOS semaphores and tasks appear to work together properly.

But the LTDC interrupt is not, and the IRQ handler looks a little odd to me.

void LTDC_IRQHandler( void )
{
  BSP_LCD_LTDC_IRQHandler();
}

void LTDC_ER_IRQHandler( void )
{
  BSP_LCD_LTDC_ER_IRQHandler();
}

void DSI_IRQHandler( void )
{
  HAL_DSI_IRQHandler( &hdsi_handle );
}

Looking into BSP_LCD_LTDC_IRQHandler is see it is defined like this:

/** @defgroup STM32F769I_EVAL_LCD_Exported_Constants STM32F769I EVAL LCD Exported Constants
  * @{
  */
#define BSP_LCD_DMA2D_IRQHandler        DMA2D_IRQHandler
#define BSP_LCD_DSI_IRQHandler          DSI_IRQHandler
#define BSP_LCD_LTDC_IRQHandler         LTDC_IRQHandler
#define BSP_LCD_LTDC_ER_IRQHandler      LTDC_ER_IRQHandler
 

It would seem the ISR handler calls itself in a one way trip to stack overflow land.

But as I mentioned for me this LTDC ISR handler is never called in any case even though I hooked up the vector in the same manner as the DSI and DMA2D IRQs.

Thanks for the help.

Niall.

P.S. The tearing effect can be seen below from a video still as the screen changes from red to green with the white text pixels appearing to spread across the right had side of the glass.

 

---

Hello,

if the text is not moving on the screen and just the background changes, then the artefacts are not tearing effects! In this case some other update problems occur.

At the moment I have no idea, what the root cause of the problem is. I never used SMX RTOS. Maybe someone else can share some ideas.

I assume, you have the FreeRTOS version up and running on your target - correct? In this case, you can try to find the difference in the runtime behaviour of your implementation and in the FreeRTOS version.

---

hi manfred,

I think you're right, the bare metal project runs fine, i think there must be some timing issue due to the RTOS being involved.

thanks.