cancel
Showing results for 
Search instead for 
Did you mean: 

Stemwin GUI not working for external SDRAM

development
Associate II
Posted on August 21, 2017 at 09:50

I have linked STemWin library. My project uses external SDRAM

When I display some progressbar or treeview or graph using internal RAM, value of progress is displayed correctlly (ex. 50%). Also treeview and graph is displayed correctly . When I am switching buffer 'aMemory' to extrernal SDRAM ( U32 aMemory[GUI_NUMBYTES / 4] __attribute__((section('.ExtRAMData')));) the value of progress is displayed strange value . Also display is flickering.

What is the problem  ?

if I check aMemory seperately then it is working ok as follows

 &sharpdefine GUI_NUMBYTES (1024) * 1024

U32 aMemory[GUI_NUMBYTES / 4] __attribute__((section('.ExtRAMData')));

uwWriteReadStatus=0;

for (uwIndex = 0; uwIndex < (GUI_NUMBYTES / 4); uwIndex++)

{

aMemory1[uwIndex] = uwIndex;

}

/* Read back data from the SDRAM memory */

for (uwIndex = 0; uwIndex < (GUI_NUMBYTES / 4); uwIndex++)

{

// if (0x87654321 != *(__IO uint32_t*) (SDRAM_BANK_ADDR + WRITE_READ_ADDR + 4*uwIndex))

if (uwIndex != aMemory1[uwIndex])

{

uwWriteReadStatus++;

}

}

I am getting 

uwWriteReadStatus as 0;That means it working.

I am using 8MB sdram with 32bit interface.

In .ld file following declaration is done

/* Specify the memory areas */

MEMORY

{

RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 192K

CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K

FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 2048K

MEMORY_ARRAY1 (xrw) : ORIGIN = 0xC0200000, LENGTH = 2M

}

...

.ARM.attributes 0 : { *(.ARM.attributes) }

.ExtRAMData(NOLOAD) : {*(.ExtRAMData)} >MEMORY_ARRAY1

Regards,

Somnath Barge

#lcd-fliker #stemwin-stm32f429
11 REPLIES 11
Posted on August 21, 2017 at 19:01

Exceeded SDRAM or internal buses' bandwidth?

JW

Posted on August 23, 2017 at 07:45

Not understand your reply. Please clarify in deep.

Somnath Barge

ebrombaugh1
Associate II
Posted on August 24, 2017 at 01:08

I'm having similar problems with STemWin when I locate the amemory[] array outside of the lower 64kB of internal SRAM. If amemory crosses the lower 64kB boundary then all manner of STemWin features fail, including off-screen rendering with memdev and simple text and graphic operations. It's almost as if the internal memory management features of STemWin are using 16-bit pointers. This situation limits the size of memdev that I can use and seriously reduces the utility of STemWin

I'm using STM32Cube V1.6.0 for the STM32F7 family which includes STemWin 532. I see the problems on both STM32F722 and STM32F746 processors.

Posted on August 24, 2017 at 10:55

 

JW

Rohit  Mishra
Associate II
Posted on August 24, 2017 at 14:40

Perform memory test on your SDRAM or SRAM to check boundary issues.

Pls find the memtest program on link below.

https://drive.google.com/open?id=0B3HQhEcX2r1wMnJxOWk1c0FuNzg

 

Regards,

Rohit Mishra.

development
Associate II
Posted on August 25, 2017 at 08:54

I have done the full memory test of sdram and results are ok.

Following are my timings

For TFT LCD  my lcd is 800*480

so for ARGB8888 mode

#define COLOR_CONVERSION_0 GUICC_M8888I

#define DISPLAY_DRIVER_0 GUIDRV_LIN_32

memory required is 800*480*4 =  1536000bytes = 1.464 MB

LCD Frame frequency is 60hz

so

Lcd memory bandwidth 

60* 1.464 = 87.84MB/sec 

My sdram is 8Mb with 32bit data width and clock is 84Mhz.(168Mhz/2)

So Memory bandwidth is 84Mhz*4byte/3 = 112MB/secs

For this setting stemwin GUI is not working

If I changed the setting in LCDConf.c as

#define COLOR_CONVERSION_0 GUICC_M565 

#define DISPLAY_DRIVER_0 GUIDRV_LIN_16 

Then Lcd memory bandwithd is 

60* 1.464/2 = 43.92MB/sec 

For this setting GUI is working for some 5 to 6minutes and then IT hangs.

Problem still not solved. My controller is STM32F429BTI.

If I set aMemory to internal memory then there is no problem.

Somnath Barge

Posted on August 25, 2017 at 10:46

so

Lcd memory bandwidth 

60* 1.464 = 87.84MB/sec 

So Memory bandwidth is 84Mhz*4byte/3 = 112MB/secs

That does not take into account the syncs, nor the SDRAM setup overhead; and leaves no headroom for the program to write into the framebuffer. That decreasing color depth helped is the very proof that the LCD controller is starving.

For this setting GUI is working for some 5 to 6minutes and then IT hangs.

That might be another, unrelated problem.

JW

Posted on August 28, 2017 at 06:08

Where did you place your frame buffer......?

Posted on August 28, 2017 at 06:52

I have placed frame buffer in SDRAM at  0xC0000000