the STemWin used external SDRAM can't pass the GUI_Init

[aizhixi]

Posted on October 17, 2013 at 12:53hello: i used the STM32F439 control#define GUI_NUMBYTES  (1024 * 1024*2)/* 32 bit aligned memory area */U32 extMem[GUI_NUMBYTES / 4];void GUI_X_Config(void){   GUI_ALLOC_AssignMemory(extMem, GUI_NUMBYTES);}In the SDRAM void GUI_X_Config(void){//Changed here only  static U32 *aMemory;  aMemory=(U32*)0xc0000000;//as GUI's RAM buffer GUI_ALLOC_AssignMemory(aMemory, GUI_NUMBYTES);}If used the SDRAM as the GUI's RAM,I can't pass the GUI_DEVICE_CreateAndLink(DISPLAY_DRIVER_0, COLOR_CONVERSION_0, 0, 0);I don't know why.the driver of LCD is OK, The SDRAM_Init(void) ,void SDRAM_InitSequence(void) used the demo.the hardware is MB1046 ,if anyone have this demo board,you can try it.In the end ,i don't know what's why .i used the SDRAM as GUI's RAM.the software is IAR6.6 .At the same time.i used the keil to debug the code .i found that it's can't jump to the c,always in the disassembly .it's strage.thank you so muck.best regardsRoyemail aizhixi@gmail.comskype aizhixi106(roy.hu)

[Tesla DeLorean]

Posted on October 17, 2013 at 16:34

Don't know, but it looks like it's trying to generate an error, and jump to a user provided callback function to manage the error. I'd imagine that callback address is NULL, and thus not being called, and that R0 is some kind of ERROR CODE or context, which the callback could act upon.

The registers at the loop would likely be quite telling. At a guess it might be reporting it can't READ/WRITE the memory region passed, or it exceeds some limits?

[Tesla DeLorean]

Posted on October 17, 2013 at 16:48

Passes through a string error message sent to

void GUI_Error(const char * s); void GUI_SetOnErrorFunc(void (* pFunc)(const char * s));

http://www.segger.com/admin/uploads/productDocs/UM03001_emWin5.pdf

[aizhixi]

Posted on October 23, 2013 at 09:15

hello，cliver:

i found a problem.i used the st-link download the code and debug ,it can't pass the GUI_Init(),however ,i used the J-link ,it can .i don't know  that's why . i have upgraded the firmware of the st-link.i don't know why?it's the dug of the st-link.or not?        thanks.best regardsroyaizhixi@gmailc.om 

[stst9192]

Posted on April 24, 2015 at 13:47

You will have to activate the CRC32 hardware peripheral. EmWin lib checks that way it is running on stm32 uC...

Tom

[rigomate2]

Posted on April 24, 2015 at 17:34

[Tesla DeLorean]

Posted on April 24, 2015 at 17:47

You will have to activate the CRC32 hardware peripheral. EmWin lib checks that way it is running on stm32 uC...

Yeah thanks, 2013 called and already knew that, this is a DIFFERENT problem.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STemWin%20GUI_Init%28%29%20crashed&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=1726

[rigomate2]

Posted on April 27, 2015 at 10:38

There is a bug with the Stlink code downloading. That's probably why it works for you using the Jlink, but does not if you use Stlink.

To verify this, just simply do a verification with the J-Flash, after you downloaded your code with Stlink, you'll most likely will get a comparison error.See my post: [DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/St-link%20Error%20in%20HEX%20parser&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&TopicsView=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/AllItems.aspx?Paged%3DTRUE%26p_StickyPost%3D%26p_DiscussionLastUpdated%3D20150424%252000%253a44%253a12%26p_ID%3D52768%26View%3D%257bF47A9ED8%252dE726%252d42BE%252dACED%252d732F13B66581%257d%26FolderCTID%3D0x012001%26PageFirstRow%3D41&currentviews=22]Stlink hex error

[Tesla DeLorean]

Posted on April 27, 2015 at 14:47

Ok, again this thread is from *2013* and Roy was *not* using ST-LINK Utilities, he'd been using IAR and KEIL directly. And had problems with memory buffers, and checks emWin did against them.

The errors with the ST-LINK Utilities .HEX parser, while interesting, don't impact most users where the debugger interfaces directly with ST-LINK. Everyone would be seeing problems, and that's simply not happening. The ST-LINK implementation is no where near as robust/industrial as the JLink, and it does a number of things differently which could explain issues short of gross ones where the memory is massively corrupted/shifted. Please can we stop digging up old threads with irrelevant input about unrelated problems you may have encountered in your own development efforts.