STM32F769-Disco with STemWin - Problem refreshing TFT

[Luis Pereira]

Posted on April 04, 2018 at 18:44

Hello,

I have a STM32F769-Disco, which I am using to study the STM32F7 peripherals for a project. I am now trying to test USB and Ethernet peripherals, writing some text do the display and here I found my problems. I can write successfully to display using emWin, but after some time, I cannot update anything on the TFT. I tried with GUI_DispStringAt, and it stop writing. I tried with Text widget with callbacks, and nothing worked. So I tried this simple code:

    GUI_DispStringAt('HELLO', 10, 20);

    GUI_DispStringAt('HELLO2', 10, 50);    while (1) {

        GUI_Delay(100);

        GUI_DispStringAt('HELLO3', 10, 70);

   }

And 'HELLO' and 'HELLO2' are written, 'HELLO3' never show up.

I want to note that I have a board, made my me, with an STM32F7 and a RGB screen. The code above work as expected, with all 3 'Hello' written. So I'm thinking this is a problem with the communication with discovery screen? Maybe DSI?

Thanks for you attention on this subject.

Sincerely

Luis Pereira

[Vitaliy Chernobay]

Posted on April 07, 2018 at 17:24

Try

    while (1) {

        GUI_DispStringAt('HELLO3', 10, 70);

        GUI_Delay(100);

   }

[Luis Pereira]

Posted on April 07, 2018 at 22:04

Hello,

I already tried that. In that way it will show the 'HELLO3' because it's right before the delay. Anything that occurs after the delay will not change in the TFT.

[Vitaliy Chernobay]

Posted on April 08, 2018 at 13:04

The function GUI_Delay(100) does not work correctly.

[Luis Pereira]

Posted on April 08, 2018 at 13:21

Could be, but what am I missing? If I place a breakpoint after the Gui_Delay, the program stops there. So it's making the delay.

The same code works in a board with the same MCU but connected with an RGB TFT interface.

Also, if I simply remove the GUI Delay, and put a counter to let's say 10000, and on the 10000 I give the command to write the 'HELLO3', I still have nothing printed. No delay, no could locked, only an incremented var in the while 1 loop.

That's what making me think the GUI_Delay is not the problem.

[Tesla DeLorean]

Posted on April 08, 2018 at 18:28

Make sure the memory involved is not buffered.

Perhaps config the MPU

/**

  * @brief  Configure the MPU attributes as Write Through for SRAM1/2.  * @note   The Base Address is 0x20010000 since this memory interface is the AXI.  *         The Region Size is 256KB, it is related to SRAM1 and SRAM2  memory size.  * @param  None  * @retval None  */static void MPU_Config(void){  MPU_Region_InitTypeDef MPU_InitStruct;

  /* Disable the MPU */

  HAL_MPU_Disable();

  /* Configure the MPU attributes as WT for SRAM */

  MPU_InitStruct.Enable = MPU_REGION_ENABLE;  MPU_InitStruct.BaseAddress = 0x20010000;  MPU_InitStruct.Size = MPU_REGION_SIZE_256KB;  MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;  MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;  MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;  MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;  MPU_InitStruct.Number = MPU_REGION_NUMBER0;  MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;  MPU_InitStruct.SubRegionDisable = 0x00;  MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;

  HAL_MPU_ConfigRegion(&MPU_InitStruct);

  /* Enable the MPU */

  HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);}

[Luis Pereira]

Posted on April 09, 2018 at 11:41

Hello Clive,

Thanks for your replay. I tried that just now, and did not change the behavior described.

[Harald Beck]

Posted on April 16, 2018 at 18:56

Hello Luis,

I have exactly the same problem with completely different hardware :)  

- STM32F469IDISCOVERY board

- CubeMX 4.25.0 - STM32Cube_FW_F4_V1.21.0

Not using the window-manager. Neither an OS. Same result!

The DSI-interface is poorly supported. I'm not talking about performance yet!!

My attempts to improve behavior brought little improvement:

- No change on de-/activating different caches of the MCU (this was a topic on SAI)- No change on changing RGB coloring to 565 - No change on lowerering clock-speeds - Little change on calling HAL_DSI_Refresh(&hdsi) after importand changes of the GUI:   - The first quarter (most left) of the display (STemWin uses 4 zones) becomes updated   - The remaining 3 of 4 quarters do not work

Unfortunately no solution...

It would be fantastic, if someone from ST could  

- Give a hint! - Explain, how do LTDC, DMA2D and DSI interact? At least the basic principles... - Interrupts on graphics (LTDC, DMA2D, DSI): how should they be sheduled/primarized? - Publish CubeMX 4.25.1 :)

At the moment, I'm really disappointed about the performance of ST.

Greetings, Harry

[Tesla DeLorean]

Posted on April 16, 2018 at 20:07

>>The DSI-interface is poorly supported.

I think that's because a lot of this is complex and requires some cross-domain understanding of how things actually work, and then being able to apply that to ST's implementation. That the people who know this stuff inside out, and are comfortable being neck deep in sketchy documentation, aren't technical writers that can explain it to everyone else, or want too.

I've used DSI on the F769I-DISCO to drive the on board panel and drive external monitors via the DSI-to-HDMI. The latter requires direct relationships between the pixel clock and the DSI clocks so the line rasters are delivered at the expected rates. While 500 MHz is the maximum, rates/lanes may need to be adjusted depending on the pixel clock and the colour depth. The DSI display itself has a complex configuration unique to the panel and its internal controller.

I suspect the type of support you expect here is quite expensive to provide. There might be other resources or access to engineering through the FAE's

I'd like to see more App Notes and Seminar Slide Decks explaining things

DMA2D - BitBlit - Frame buffer manipulation

LTDC - Raster Engine - RGB delivery at pixel clock

DSI - Data Transport - Bit Stream - Command/Data channel