SDRAM Cube 4.18 vs 4.22 on STM32F746G-Disco

[markus239955_stm1_stmicro_com]

Posted on December 18, 2017 at 11:16

Hello everyone,

I have some trouble using the SDRAM of the STM32F746G-Disco as a framebuffer for the LTDC with CubeMX 4.22 instead of CubeMX 4.18.

I configured my Project according to the Pinout of the Disco-Board and it worked fine with CubeMX 4.18. The SDRAM was configured like

in the BSP examples provided with CubeMX (I noticed that CubeMX does not allow WriteRecoveryTime set to 2 like in the BSP, only 3  or higher is possible).

I added my own code to initialise the SDRAM IC which is not generated by CubeMX. CubeMX initialises the FMC only. With CubeMX 4.18, everything works fine.

Also a Project created with the BSP files and CubeMX 4.18 and 4.22 work fine. After updating my Project to CMX 4.22, the SDRAM did not work correctly as

Framebuffer any more. Every 64. pixel, there are vertical lines and also there ist some random Pixel snow running all over the Screen (I am using CLUT 8 as colour mode).

The intended Screen Content is still visible but disturbed. The graphics data shown on the Screen is read from the internal Flash.

But I can fix this by flashing first my CubeMX 4.18 Project binary or the BSP Project binary of CMX 4.18 or 4.22 and afterwards flashing my CMX 4.22 Project binary.

Than, the SDRAM is still initialised correctly and working perfect as a Frame buffer. Only a power cycle resets the Hardware so my Project binary will not work properly.

This leads me to the conclusion that some Registers are not set correctly with my code, but after comparing the BSP Projects with my CMX 4.22 Project, I found no clue

what is going wrong. Migrating to CMX 4.23 crashed the whole Project, so i returned to 4.22, because everything except the SDRAM initialisation works there.

As a desperate step, i tried to copy and paste the BSP code into my Project to initialise the SDRAM without CMX, but I did not have success, the distortions of the

TFT Output are still the same.

Can someone give me a hint what is going wrong in my SDRAM initialisation code I attached in the Zip file ? A example using SDRAM with a CubeMX 4.22 Project would help, too.

Best regards,

Markus.

[Vitaliy Chernobay]

Posted on January 07, 2018 at 00:15

My init of SDRAM for example

________________ Attachments : main.c.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hy0s&d=%2Fa%2F0X0000000b4h%2Fdy51ycUWAph5CS_I8Fmn4EFwWcMtyzu0GsM7e0fl7AU&asPdf=false

[Bogdan Golab]

Posted on January 07, 2018 at 22:35

I am not sure what you are going to achieve - probably you want to generate project skeleton using CubeMX. Some time ago I created such template using CubeMX 4.21.0 - maybe it will help. I hope you will be able to migrate it to CubeMX 4.23.0:

https://community.st.com/0D50X00009bMM6pSAG

 

[Vitaliy Chernobay]

Posted on January 08, 2018 at 00:57

I made a project with STM32F769BI with FMC(SDRAM) 32bit, LTDC(STemWin) 24bit RGB 800x480, SDMMC(FATFS), FreeRTOS & outher.

CubeMX 4.23.0 have bugs with SDMMC config.

My project for 4.22 & 4.21 does not work for this configuration.

[markus239955_stm1_stmicro_com]

Posted on January 18, 2018 at 13:36

Thanks to all who want to help.

After comparing several times the parameters from my project, the BSP project and the examples given here, I was sure that not the parameter values are the reason for the misbehaviour of the SDRAM.

By accident, I noticed that the optimisation level causes the problem. I use SW4STM32 as my compiler suite.

-o for debug works fine, any other optimisation level causes problems. I now assume that the SDRAM initialisation sequence is too fast for the SDRAM chip with active optimisation. Maybe the 1ms delay is skipped or something else. I want to use -o3, because this gives me twice the fps than -o debug. Has anyone else encountered the same Problems ?

DCache is already off because it scrambles the Screen Output with DMA and all Screen drawings are done with DMA(2D). TCM or AXI mode makes no difference.

Any suggestions ?

[markus239955_stm1_stmicro_com · Accepted solution]

Posted on February 06, 2018 at 16:28

Finally the Problem is solved. With CubeMX 4.22, only optimisation Level -01 works. I updated the Project to CubeMX 4.24 and now, optimisation Level -o3 is possible. Gives a fine Performance boost compared to -o debug. D-Cache is still disabled because it creates massive draw Errors. Using DCacheFlush before DMA transfers causes a massive Performance drop without avoiding all draw Errors.