STM32F4 DMA problem since firmware package 1.15

Karsten Koop · ‎2017-07-06

Posted on July 07, 2017 at 08:45

We are using an STM32F429 together with external SRAM, SD card and LCD display, utilizing STemWin. The framebuffer for the display is located in the external SRAM, as is another buffer that is used to write to the SD card using DMA. After upgrading the HAL library from 1.5 to 1.15, we noticed a hang when writing to the SD card, but only when the display is active, i.e. after a call to GUI_Init().

This can be reproduced on the STM32429I-EVAL board: as soon as both buffers are placed in the external SRAM, this hang on DMA transfer occurs, but only in 1.15, not in older versions. When placing both buffers in external SDRAM or one into internal RAM the problem goes away.

After comparing the library source between version 1.5 and 1.15, I found the breaking change the removal of the call to `__HAL_DMA_DISABLE(hdma)` in `HAL_DMA_Start_IT`. After adding this call in the 1.15 version, it works as before.

So the question: Is this a BUG in the hal library code, or is the removal intentional? It seems the reference manual also states that DMA has to be disabled before the DMA registers can be written. So why was the call removed? It looks the same in 1.16.

#dma-problem #stm32f4

bbee · ‎2017-07-07

Posted on July 07, 2017 at 11:37

Lower the IRQ Priority of the SD DMA streams so that they can be interrupted by the FMC others.

Check if you hang in SD_DMA_RxCplt, ST placed a possible endless loop in there (at least in Version 1.14)

Karsten Koop · ‎2017-07-07

Posted on July 07, 2017 at 11:49

Further clarification: The writing hangs because it waits on the DMA to finish, i.e. the call to the BSP_SD_WriteCpltCallback(), which never comes because the DMA probably never even starts. The reference states about the enable bit in the

DMA_SxCR

register: '

When this bit is read as 0, the software is allowed to program the Configuration and FIFO bits registers. It is forbidden to write these registers when the EN bit is read as 1.

' The additional call to __HAL_DMA_DISABLE(hdma) resets this bit, and I can confirm that the bit is initially set when the hang occurs.

The question would be why this bit can be set, when the DMA access to the SD card always waits until the DMA finished, and why enabling the display causes this. It seems like the DMA of the framebuffer interferes in some way with this other DMA, although they are different streams.