How to handle DMA2D Transfer Error

[Nikil Rao]

Hi,

I'm working with touchgfx on an STM32F769I board and I'm facing a problem where some times the DMA2D throws a transfer error (DMA2D_ISR_TEIF) during the running of my application. In the touchgfx library files (STM32F7HAL_DSI.cpp) I see that the DMA2DIRQHandler signals a DMA interrupt only when it gets a Transfer Complete Interrupt and the Transfer Error case is not handled at all. Does anyone know why the transfer error could be happening and how to handle it? If I call signalDMAInterrupt() even when I get a transfer error will the application have a glitch and continue normally? Right now, since I don't handle it the whole system freezes. Thanks in advance!

Nikil

[Martin KJELDSEN]

Hi @Nikil Rao​,

How did you create this project? What is the nature of this error; Does it happen consistently in the same place? How often? The DMA2D chip transfers data to the framebuffer memory - Are you sure it's set up correctly? Can you display anything without using DMA2D ? (e.g. simple boxes).

If you could give me a bit more information that would be helpful.

Thanks!

[Martin KJELDSEN]

Any update on this, @Nikil Rao​ ?

[Nikil Rao]

@Martin KJELDSEN​ Sorry for the late reply. It never happens in the same place and it doesn't seem to be connected with the MCU/Graphics load as it happens with just one static screen and no transitions as well . I'll try it without the DMA2D as you suggested.

Our Configuration:

• Core clock 216Mhz
• QSPI in memory Mapped mode with 108MHz with a Micron Flash.
• Dual Framebuffers in SDRAM-16bit (100MHz Clock)
• TFT Display with 320x320 Resolution, PixelClock 30MHz
• 1 layer LTDC
• DMA2D and LTDC priority 7

I recently changed our pixel clock speed from 41.7MHz to 30MHz as we had FIFO underruns and GUI glitches. The device freezes seem to have increased after I did this but since they are very random and hard to reproduce I cannot say that the clock change directly caused more device freezes. I reverted the fix and I was able to get the same device freeze but less frequently.

It looks very similar to this problem - https://touchgfx.zendesk.com/hc/en-us/community/posts/115001456885-Sporadic-crash-on-STM32F4 but I checked our code and we haven't enabled the  QSPI->CR_TCEN Timeout counter. Most of the times when the freeze happens the debugger also disconnects and I have no clue where the code stopped working. A couple of times when a freeze happened it hit my breakpoint in the DMA2D handler where I was able to see that a transfer error happened but most of the times I don't hit the breakpoint and just lose connection to the debugger (Seems to point to a bus error)

[Martin KJELDSEN]

Hi @Nikil Rao​,

Thanks for the information. Maybe we're dealing with memory contention issues - Could you try calling  hal.lockDMAToFrontPorch(true); in your board configuration? This ensures that the DMA will not try to access the framebuffer memory while the LTDC is reading from it and clocking pixels to the display.

[Martin KJELDSEN]

You could also try having the framebuffer in internal ram, just as a test.

[Laurent Golay]

Hi @Nikil Rao​  and @Martin KJELDSEN​ ,

Do you have any update about this issue?

We are facing the exact same problem.

We made a workaround by signaling DMA interrupt even in transfer error cases... and it seams that everything is continuing working normally even if it happens. But I'd prefer to be sure that there is no other impact on system.

Thanks in advance

[Martin KJELDSEN]

Hi @Laurent Golay​,

So you're saying that you cannot visibly see that elements are missing even if you continue on errors?

[Martin KJELDSEN]

What is DMA2D transferring from and to? Maybe there is some memory that it cannot access.