Showing results for 
Search instead for 
Did you mean: 

STemWin: drawing a GIF with a memory assigned to the SDRAM

Alex Gab
Associate III

Posted on May 26, 2018 at 08:06

Hello to everyone,

let me please ask a question.

I'm using STemWin on STM32F777ZI controller for GUI development on a custom board. 

The board has SDRAM (MT48LC32M16A2, 512 Mbit) connected to the controller through FMC Bank1 (start address is 0xC0000000).

The 10.4 inch display (1024x768) is connected to the controller through LTDC.

I'm using Atollic True Studio IDE.

Some configuration options in LCDConf.c:

#define GUI_NUM_LAYERS 1
#define LCD_LAYER0_FRAME_BUFFER 0xC0400000
#define LCD_LAYER1_FRAME_BUFFER 0xC0800000

In CUIConf.c:

#define GUI_NUMBYTES 0x0400000
// in GUI_X_Init():
static U32 aMemory[GUI_NUMBYTES / 4] __attribute__ ((section(".sdram_data")));

As we can see aMemory assigned to ".sdram_data" section configured in linker *.ld file. It has a start address at 0xC0000000 and a size of 0x0400000, so it wouldn't conflict with a frame buffer memory for layer 0 which has a start address at 0xC0400000. Watch window in IDE shows these correct addresses (aMemory shows 0xC0000000and layer_prop[0].address shows 0xC0400000).

I've also read the LTDC manual from ST (AN4861) attentively and configured all the recommendations that described in this manual (SDRAM and LTDC clock restrictions and MPU regions configuration on SDRAM and internal RAM). SDRAM clock is 100 MHz, and LTDC clock is 50 MHz.

I'm successfully configured and initialized STemWin ("Hello, world" etc... basical drawing functions from 2D graphical library...)

After that I made a simple 1024x768 BMP picture in GIMP (Green text "This is a BMP" on the yellow background), then I optimized it using Bitmap Converter, then converted it to C-array using Bin2C for GUI_BMP_Draw() function and finally got it on the screen:

0690X00000604TvQAI.jpgNext I made a same GIF picture ("This is a GIF"), unoptimized it as described in emWin manual (exactly in emWin UM03001, not in StemWin manual StemWin532.pdf) then again used Bitmap Converter and converted the GIF to C-array for using with GUI_GIF_Draw()

And got this one:

0690X00000604C1QAI.jpgSeems that only few first lines of the GIF displayed. GUI_GIF_Draw() returned 1. That is error.

Next in function GUI_X_Config() I reconfigured aMemory location to its default address in internal RAM.

static U32 aMemory[GUI_NUMBYTES / 4]; // __attribute__ ... deleted. Watch window shows 0x20001308 address.

Had to reduce the size of aMemory to 300 KB as internal RAM is only 512 KB on the chip:

#define GUI_NUMBYTES (300 * 1024)


Frame buffer location for layer 0 remains unchanged: 

#define LCD_LAYER0_FRAME_BUFFER 0xC0400000 // in SDRAM

C-array containing GIF data also remains unchanged. The only change is aMemory relocation from SDRAM to internal RAM.

And got it:


GUI_GIF_Draw() returned 0. Works fine.

Can anyone suggest what is wrong with the drawing a GIF with aMemory allocated in SDRAM? First I thought that problem is in SDRAM, but GUI_BMP_Draw() and GUI_DrawBitmap() work properly regardless of aMemory allocation. May be I missed some options when I configured STemWin? Or while configurating peripherals (DMA2D, FMC, MPU regions...)?

Some configuration screens from STM32CUBEMX.





0690X00000604g1QAA.jpg 0690X00000604kgQAA.jpg


0690X00000604b0QAA.jpg0690X00000604kqQAA.jpgColor frame buffer start address for Layer 0 reassigned to 0xC0400000 in LDC_X_Config()



(See attached image SDRAM)

It is critical for my development to use GIFs as they have compact size and the board has only internal flash on the chip (2 MB).

In addition, I'm going to use Window Manager and use GIFs as background images with different widgets over it. So I need to use Memory Devices for fast painting when invalidating windows and I should have sufficient RAM for that purposes as internal RAM is not enough.

I can provide an additional code sections if it is needed.

Thanks for your time.

Posted on May 27, 2018 at 20:08



Associate III
Posted on May 31, 2018 at 09:48

Send the GIF generated code (at lease the arrays declaration), and show the complete



call with arguments.

You let the linker decide where to place aMemory in SDRAM but assigned fixed address to the framebuffer. You may also use __attribute__  for framebuffer memory allocation. This is what I did and now it is easier to check SDRAM memory use with the atollic memory viewer.


Some other clues :

  • use a smaller GIF size to check that memory size is a problem

  • increase emwin memory pool, you have setted 1 MB.

  • try your code on PC, emwin is distributed with a lib compiled for PC (check on segger site).

  • try segger forum.

  • First if you pretend to youse the window manager you should workd with the associated function, so for GIF the IMAGE_SetGIF() handles It.

Posted on May 31, 2018 at 11:08

Hello, Selso!

Thank you for your reply.

I had requested with this problem to Segger forum:

There is my full simple project attached to the thread. I attached the same project here (it is for System Workbench IDE)

The GIF has a small size (~5K). I increased memory pool to 32 MBytes (please see my thread on the Segger forum). I simply split in half SDRAM addressable space (lower 32 MBytes to memory pool, higher 32 MBytes to frame buffer layer 0). On a PC simulation all the code works fine (GUI_GIF_Draw() and also Window Manager IMAGE widget using IMAGE_SetGIF()). On the real board both of these functions work properly only when I assign memory pool to internal RAM (no '__attribute__...'). The problem appears only when I assign memory pool to SDRAM (with '__attribute__....'). However,




work properly regardless of

memory pool

allocation. And also their 'twin' functions

IMAGE_SetBMP() and

IMAGE_SetBitmap() when using Window Manager.

It seems that problem is in MPU regions configuration as I'm using STM32F777ZI chip.

AN4861 contains recommendations how to configure the MPU regions in case of graphical memory allocation in SDRAM.

AN4838, AN4839 contains recommendations how to configure the MPU regions as such.

Cortex-M7 has a complex system to handle access to the memory regions. And I'm currently having a hard time configurating the MPU regions for SDRAM space.

I also created a new thread here (I thought it is a new problem and I can start a new thread):

Thanks for your time.


Attachments : :

Alex Gab
Associate III
Posted on June 01, 2018 at 23:56

I'm sorry, at first with inexperience I've been making a mess with dublicate threads.

Now that is the only thread:

Thanks to all.