cancel
Showing results for 
Search instead for 
Did you mean: 

Display Freeze

AB595
Associate II

Hello All,

I'm working on my own project using an STM32H573x microcontroller. I use TouchGFX to design the display graphics, and the FMC module to interface with an ILI9341 display controller. Data is transferred to the FMC banks using DMA in linked-list mode.

After some time, when the display is flooded with updates, it completely freezes. During debugging, I noticed that the DMA somehow stalls, and the interrupt for transfer completion never triggers again.

I tried restarting the DMA module after it crashes, and it does work again, but the display performance becomes poor. This is understandable, since resetting the DMA takes time and causes some frames to be lost. I also noticed that after the first occurrence of the error, the reset DMA function gets called more and more often, which means the error is happening more frequently. This made me suspect an issue with the FMC configuration. However, I checked against the datasheet, and it seems correct for my case.

Has anyone experienced a similar issue, or could provide any tips in such a situation?

3 REPLIES 3
JohanAstrup
ST Employee

Hello @AB595.

I have not experienced a similar issue to the one you are describing.

Are you using 8-bit or 16-bit FMC?
There are a few different H5 TBSs using FMC for display available in TouchGFX Designer that you can use as references:

  1. NUCLEO-H563Zl + GFX02Z1: 8-bit FMC, double framebuffers, and DMA in linked-list mode.
  2. NUCLEO-H563Zl + RVA35Hl: 8-bit FMC, partial framebuffer, and simple DMA transfer.
  3. Two TBSs for STM32H573I-DK: 16-bit FMC, double framebuffer, and DMA in linked-list mode.

Another approach is to manually divide the transfer to the display into three or four separate transfers, depending on the size of the display. Ensure that the transfers are small enough to remain within the DMA's maximum transfer size. By doing this, you avoid the complexity of configuring the DMA in linked-list mode. I would expect this approach to make it easier to debug.

Best regards,
Johan

AB595
Associate II

Hello @JohanAstrup 

I'm using a 16-bit FMC.
I started my project based on an example from ST. I don’t remember exactly, since I began the project almost a year ago, but it may have been the STM32H573I-DK: 16-bit FMC, double framebuffer, and DMA in linked-list mode example that I used as a reference for the kickoff.

Now I’m working with a custom-designed PCB for a specific project. Everything was running quite well until I started stressing the display with requests (which should be considered a normal scenario in my case).

Is there any other tip or something else i can check instead of doing a core change for the way i handle the transfer of the frame?

AB595
Associate II

Hello,

Here is an update that might be of interest. I have implemented a workaround that helps reduce the issue and makes the system behave more reliably; however, I still need to determine the root cause.

I force the dmaCompleted flag to be set to true every 20 ms, under the assumption that no DMA transfer should take longer than 20 ms. This flag is checked in the SignalTearingEffectEvent function within the TouchGFX HAL. I then send the data to the DMA regardless, and check the return value of the function that triggers the DMA transfer. Once this function fails to trigger a transfer, I reset both the DMA and FMC controllers. After the reset, the system resumes normal operation until the error occurs again.

This workaround acts more like a recovery mechanism, but I still haven’t identified the actual root cause of the error.

Is there any tip that can help to move forward towards finding the root cause?