STM32H735 Disco HAL DMA2D Not Working

[TRadd.1]

Since a few days I own an STM32H735 Disco board. But I can't get HAL DMA2D to work correctly. The following code shall copy a line of pixels from RAM into the framebuffer:

DMA2D_HandleTypeDef hdma2d;
 
static void ConvertLineToRGB(uint32_t *pSrc, uint32_t *pDst, uint32_t xSize)
{
  hdma2d.Instance = DMA2D;
 
  /* Configure the DMA2D Mode, Color Mode and output offset */
  hdma2d.Init.Mode         = DMA2D_M2M;
  hdma2d.Init.ColorMode    = DMA2D_OUTPUT_ARGB8888;
  hdma2d.Init.OutputOffset = 0;
 
  /* Foreground Configuration */
  hdma2d.LayerCfg[1].AlphaMode = DMA2D_NO_MODIF_ALPHA;
  //hdma2d.LayerCfg[1].InputAlpha = 0xFF;
  hdma2d.LayerCfg[1].InputColorMode = DMA2D_INPUT_ARGB8888;
  hdma2d.LayerCfg[1].InputOffset = 0;
 
  /* DMA2D Initialization */
  if(HAL_DMA2D_Init(&hdma2d) == HAL_OK)
  {
    if(HAL_DMA2D_ConfigLayer(&hdma2d, 1) == HAL_OK)
    {
    	HAL_DMA2D_Start(&hdma2d, (uint32_t)pSrc, (uint32_t)pDst, xSize, 1);
    	HAL_DMA2D_PollForTransfer(&hdma2d, 25);
    }
  }
  //memcpy(pDst, pSrc, xSize * 4);
}

I can see in the debugger that HAL_DMA2D_Start() writes all zeroes into the target memory, instead of copying the data from pSrc. If I activate the memcpy() below, the data is copied correctly and the LCD display shows the correct graphics. I have the impression there is a bug in the HAL.

Indeed there is a similar function LL_ConvertLineToRGB() in the BSP (Board Support Package). But in the BSP the DMA2D code is deactivated by #define and pixels are copied one by one by code. It seems, DMA2D did not work at ST either. Has someone an idea?

[waclawek.jan]

Is the source properly aligned and in memory to which DMA2D has access?

Read out and check/post content of DMA2D registers.

JW

[TRadd.1]

pSrc is uint32_t * 0x24000d08 <buffer>

DMA2D is:

hdma2d DMA2D_HandleTypeDef {...}

Instance DMA2D_TypeDef * 0x52001000

CR volatile uint32_t 196608

ISR volatile uint32_t 0

IFCR volatile uint32_t 0

FGMAR volatile uint32_t 134256514

FGOR volatile uint32_t 0

BGMAR volatile uint32_t 0

BGOR volatile uint32_t 0

FGPFCCR volatile uint32_t 4278190082

FGCOLR volatile uint32_t 0

BGPFCCR volatile uint32_t 0

BGCOLR volatile uint32_t 0

FGCMAR volatile uint32_t 0

BGCMAR volatile uint32_t 0

OPFCCR volatile uint32_t 0

OCOLR volatile uint32_t 4278190080

OMAR volatile uint32_t 0

OOR volatile uint32_t 448

NLR volatile uint32_t 2097208

LWR volatile uint32_t 0

AMTCR volatile uint32_t 0

RESERVED uint32_t [236] 0x52001050

FGCLUT volatile uint32_t [256] 0x52001400

BGCLUT volatile uint32_t [256] 0x52001800

Init DMA2D_InitTypeDef {...}

Mode uint32_t 0

ColorMode uint32_t 0

OutputOffset uint32_t 0

AlphaInverted uint32_t 0

RedBlueSwap uint32_t 0

BytesSwap uint32_t 0

LineOffsetMode uint32_t 0

XferCpltCallback void (*)(struct __DMA2D_HandleTypeDef *) 0x0

XferErrorCallback void (*)(struct __DMA2D_HandleTypeDef *) 0x0

LayerCfg DMA2D_LayerCfgTypeDef [2] 0x240013a0 <hdma2d+40>

LayerCfg[0] DMA2D_LayerCfgTypeDef {...}

InputOffset uint32_t 0

InputColorMode uint32_t 0

AlphaMode uint32_t 0

InputAlpha uint32_t 0

AlphaInverted uint32_t 0

RedBlueSwap uint32_t 0

ChromaSubSampling uint32_t 0

LayerCfg[1] DMA2D_LayerCfgTypeDef {...}

InputOffset uint32_t 0

InputColorMode uint32_t 0

AlphaMode uint32_t 0

InputAlpha uint32_t 0

AlphaInverted uint32_t 0

RedBlueSwap uint32_t 0

ChromaSubSampling uint32_t 0

Lock HAL_LockTypeDef HAL_UNLOCKED

State volatile HAL_DMA2D_StateTypeDef HAL_DMA2D_STATE_RESET

ErrorCode volatile uint32_t 0

[TRadd.1]

PS: I am calling BSP_LCD_Init(0, LCD_ORIENTATION_LANDSCAPE) in main(), which should initialize DMA2D.

[Ons KOOLI · Accepted solution]

Hi @TRadd.1​ 

When working with DMA for STM32H7 devices, you should pay attention to the memory allocation.

The default memory used by most of ST projects is DTCM which is not accessible by DMA in STM32H7 devices.

So, you should change it to something else which is accessible by DTCM (for example AXI SRAM 0x2400 0000). Please refer to the corresponding reference manual, under System Architecture section.

In most cases this can solve the issue. However sometimes for more advanced applications, the D-Cache can affect the functionality of DMA transfers, since the default cache policy for product SRAMs is normal memory (cacheable). Cache will hold the new data in the internal cache and don't write them to SRAM memory. However, the DMA controller loads the data from SRAM memory and not D-Cache. Same behavior can happen when reading data, as DMA will update buffers in SRAM, and the content of SRAM will not be immediately visible to CPU as CPU will see previously cached data. This will result in data coherency issues.

So if changing memory allocation did not solve the problem, you have to disable the D-Cache. But I think in your case changing memory allocation to AXI SRAM (for example) is enough to solve the issue.

Best Regards,

Ons.

Note: If the problem is resolved, please mark this topic as answered by selecting Select as best. This will help other users find that answer faster.

[TRadd.1]

Disabling the caches solved the problem. Thanks for your help.

[Piranha]

Not using a cache management or MPU is a bug!

Read my answer for a proper solution:

https://community.st.com/s/question/0D53W00000oXSzySAG/different-cache-behavior-between-stm32h7-and-stm32f7