STemWin's GUI_Init() hangs in call to DMA2D_FillBuffer()

[David Brooks]

Posted on June 01, 2016 at 22:41

This appears to be a different GUI_Init() hang problem than those mentioned elsewhere on the Forum. My app enables the CRC module via the following Cube-generate call MX_CRC_Init(). This code is running on the 469i_Disco board.

My app runs properly without STemWin using the following Cube-generated initialization code:

int main(void)

{

  /* USER CODE BEGIN 1 */

  /* USER CODE END 1 */

  /* MCU Configuration----------------------------------------------------------*/

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */

  HAL_Init();

  /* Configure the system clock */

  SystemClock_Config();

  /* Initialize all configured peripherals */

  MX_GPIO_Init();   MX_DMA_Init();   MX_DMA2D_Init();   MX_I2C1_Init();   MX_SDIO_SD_Init();   MX_TIM3_Init();   MX_RTC_Init();   MX_FATFS_Init();   MX_FMC_Init();   MX_LTDC_Init();   MX_DSIHOST_DSI_Init(); But after several days of trying to integrate STemWin into my project and finally getting it to compile, the code hangs in a call to DMA2D_FillBuffer() at this statement:   /* Wait until transfer is done */   while (DMA2D->CR & DMA2D_CR_START)   {   } I just cant figure out where the problem is and would appreciate some assistance.

[Nesrine M_O]

Posted on June 02, 2016 at 12:21

Hi dmbrooks44,

I recommend you to have a look to the STemWin applications under the STM32F4 cube firmware package, it may be helpful:STM32Cube_FW_F4_V1.12.0\Projects\STM32469I-Discovery\Applications\STemWin-Syrine-

[David Brooks]

Posted on June 02, 2016 at 15:12

I've already done that.  Unfortunately, those examples use the ''old'' BSP files, not Cube-generated files. Essentially, these examples only call BSP_SDRAM_Init() prior to calling GUI_Init(). So I have been comparing the Cube-generated MX_DMA_Init(), MX_DMA2D_Init(), MX_FMC_Init() and MX_DSIHOST_DSI_Init() files to the settings used in BSP_SDRAM_Init(). At this point, I feel like I have configured Cube according to BSP_SDRAM_Init(), but I am obviously missing something. This really shouldn't be this difficult. Hasn't anyone integrated STemWin into a Cube-generated project?

And keep in mind that my Cube-generated project runs just fine on the intended 469i-Disco board before I try to integrate STemWin. So I have a high confidence level in the Cube configuration settings. However, I have no idea (No documentation?) of what configuration settings STemWin requires. To be fair and complete, although my working code calls the various MX_xxx_Init() functions, it still calls BSP_LCD_Init() before using the LCD. So the Cube settings are probably being overwritten. I will investigate this further.

[greg239955_stm1]

Posted on July 06, 2017 at 05:21

Have you had any success with this? I'm stuck on the exact same problem, but using a 429 micro on my own board design (very close to the 429 Discovery.)

Using Cube generator 4.21.0 and F4 FW V1.16.All of the DMA2D registers look correct, it just refuses to start the transfer.

[bbee]

Posted on July 06, 2017 at 11:39

GUI_Init calls LCD_X_Config in the display driver which in turn calls LCD_LL_Init in the driver. Be sure to remove all the stuff in the LL_Init functions which is realted to LTDC and DMA2 configuration and replace it by calls to your MX_LTDC_Init and MX_DMA2_Init. Therefore remove the according init functions in main.

You should also disable the DMA2D interrupt in the MX config as it is not needed because the LCD driver polls the DMA2D controll register instead to react on ISR callbacks.

Be sure that your SDRAM (FMC) is configured and working before you call any GUI functions because the SDRAM is used as display buffer and any memory needed by STemWin comes from there.

Have a look into SystemInit_ExtMemCtl (system_stm32f4xx.c) where FMC is configured immediately after startup to gain access to  SDRAM. Configuring SDRAM in main using MX_FMC_Init may be too late.

[greg239955_stm1]

Posted on July 07, 2017 at 01:35

Thanks, fixed now. I was calling BSP_SDRAM_Initialization_sequence() from my Hal msp function, which was too early.

[Jona]

"You should also disable the DMA2D interrupt in the MX config as it is not needed because the LCD driver polls the DMA2D controll register instead to react on ISR callbacks"

AHa! I have been trying to determine how STemWin / SDRAM and DMA2D actually work in my new code.. It's running but at one point I found that the CEIF bit in the DMA2D->ISR register was being set. Thinking I needed to have some kind of IRQHandler I proceeded to investigate. This is all new code to me and a new processor. So I looked and .. it appeared STEmwin is set up as a polling system and does not use. I guess my question is:

SANITY CHECK:

So, then would it be natural and harmless to see the CEIF bit to be set during operation. Since it is a polling system, that bit being set is something I can ignore?

Thank you