STemWin GUI_Init() crashed

[mail2]

Posted on July 29, 2013 at 13:43

Hi,

I have Downloaded STemWin from the STM Website and i have tried to build a simple ''Hello World'' Application on my STM32F207 with KEIL 4.72a, but my Application goes into an infinite Loop in GUI_INIT(). I have found a hint onn the Segger Website, that GUI_Init() tries to acces the provided memory area with 8, 16 and 32 Bit accesses. This memory Area will be assigned by a call to GUI_X_Config() (provided by my code), but GUI_X_Config will never be called by GUI_Init(). I used the Library files STemWin520d_CM3_Keil.lib (without OS) and STemWin520d_CM3_OS_Keil.lib (with OS support). What can i do to find the problem? Thanks Martin #stemwin

[mail2]

Posted on July 31, 2013 at 13:11

Hello,

Is/was someone able to use the precompiled STemWin libraries with KEIL MDK and touch me into the right direction? Thank you Martin

[Tesla DeLorean]

Posted on July 31, 2013 at 17:19

Given the response, probably not, I'm using head-less systems.

[adrian]

Posted on August 01, 2013 at 08:15

It's a pain in the backside.

We originally used the ST 3220G dev board to do a few tests while we were waiting our own board back, so we hooked up our LCD and I started hacking away creating an EM win program that would work.I kept ending up in a loop in some code, I eventually managed to figure out that this was the error handler in the EM win libraries and was able to look at the registers to figure out the error code, there was a problem with the memory.  We eventually traced this to being an address line fault between the processor and the RAM on the dev board, so ST swapped it out and the code ran correctly after that.Debugging EM win stuff would be so much easier if they'd provided a debug version with the error callbacks so that you can figure out what's going on, it's quite difficult at the moment and I think I was only really able to do it by stepping through the disassembly on the EMwin calls during startup.If you can post up your init code I could take a look at ours and see if there's anything obvious.Adrian

[mail2]

Posted on August 01, 2013 at 09:52

Hi,

I have created a new KEIL Project for the STM32F207 and inserted empty function definitions for GUI_X_Config, LCD_X_Config and the os support functions.My main looks like:int main(){ GUI_Init(); return 0;}GUI_Init never returns and my provided callback functions are never called.When i single step through the assembler instructions, than a get:                 GUI_Init:0x0800066C 4812      LDR      r0,[pc,#72]  ; @0x080006B80x0800066E B510      PUSH     {r4,lr}0x08000670 6801      LDR      r1,[r0,#0x00]0x08000672 F0210101  BIC      r1,r1,#0x010x08000676 6001      STR      r1,[r0,#0x00]0x08000678 4810      LDR      r0,[pc,#64]  ; @0x080006BC0x0800067A 2101      MOVS     r1,#0x010x0800067C 6081      STR      r1,[r0,#0x08]0x0800067E 4910      LDR      r1,[pc,#64]  ; @0x080006C00x08000680 6001      STR      r1,[r0,#0x00]0x08000682 6800      LDR      r0,[r0,#0x00]0x08000684 490F      LDR      r1,[pc,#60]  ; @0x080006C40x08000686 4288      CMP      r0,r10x08000688 D000      BEQ      0x0800068C0x0800068A E7FE      B        0x0800068A  <---- infinite Loop!!The CPU hangs here.I don't know why, wait i know why, the comparison CMP r0,r1 fails, but i don't know what is going on here.Martin

[adrian]

Posted on August 01, 2013 at 10:03

Humn.

Just out of interest, you said you'd inserted empty functions...maybe the compiler is doing something odd (I know they're callbacks...but).Can you make them increment a  static global variable and put breakpoints on the increment to double check that they're definitely not getting there?If they're still not, then maybe it's a stack issue?I just realised that you were talking about the ST emWin libraries, I read keil and MDK in your post an assumed just assumed that you'd be using the emwin that comes with keil. (which definitely doesn't have the required callbacks for error handling), maybe the ST ones do.  I can't remember where/what they are, but they're documented in one of the emwin headers as being a compile time option (obviously ST will have had to compile them with the option as they're supplying object code), might be worth checking.We have a GUI task and the first thing it calls is GUI_Init (same as you) but it does get to the LCD_X_Config and GUI_X_Config callbacks.Odd.Edit:GUI_X_LogGUI_X_WarnAre the two functions which permit some debugging rather than spin-locking, but I guess it depends whether the libraries are available with support for these.Have you also double checked that all your OS support is correct and returning sane values?We have all these implemented and using the appropriate OS mechanisms:GUI_X_GetTime(void)void GUI_X_Delay(int ms)void GUI_X_Init(void)void GUI_X_ExecIdle(void)void GUI_X_InitOS(void)void GUI_X_Unlock(void)  void GUI_X_Lock(void)  U32  GUI_X_GetTaskId(void) void GUI_X_WaitEvent(void) void GUI_X_WaitEventTimed(int Period)void GUI_X_SignalEvent(void)

[mail2]

Posted on August 01, 2013 at 11:58

Hi,

Yes, its ST emWin.I have checked that the linker links my stub functions, this is OK.GUI_Init() is the first function to call an GUI_Init should call my (stub) GUI_X_Config at first, but - as my single stepping shows - it hangs just before the call to GUI-X-Config.Martin

[Tesla DeLorean]

Posted on August 01, 2013 at 13:41

It looks to be writing test patterns to memory, then checking them.

Where is the video buffer? And can you test it manually? In on FSMC is that configured correctly?

[mail2]

Posted on August 01, 2013 at 14:01

Hello clive1,

No Video memory, no vlcd driver, nothing.The STemWin library function GUI_Init should call GUI_X_Config. GUI_X_Config will provided by me to set a memory Area for the lib to work with.After this call, GUI_Init should also call two functions - provided by me - to initialize and provide LCD and OS related functions.But none of these functions will be called. The dissasembly of GUI_Init shows, that these function will be called after the endless loop line, when cpm r0, r1 succeeded.If looks like seomething like if (! a!= b) for(;;) ;So something fundamental is missing by me or the provider of the Library (ST) has build a non working version.Martinlittle longer listing of GUI_Init:                 GUI_Init:0x0800066C 4812      LDR      r0,[pc,#72]  ; @0x080006B80x0800066E B510      PUSH     {r4,lr}0x08000670 6801      LDR      r1,[r0,#0x00]0x08000672 F0210101  BIC      r1,r1,#0x010x08000676 6001      STR      r1,[r0,#0x00]0x08000678 4810      LDR      r0,[pc,#64]  ; @0x080006BC0x0800067A 2101      MOVS     r1,#0x010x0800067C 6081      STR      r1,[r0,#0x08]0x0800067E 4910      LDR      r1,[pc,#64]  ; @0x080006C00x08000680 6001      STR      r1,[r0,#0x00]0x08000682 6800      LDR      r0,[r0,#0x00]0x08000684 490F      LDR      r1,[pc,#60]  ; @0x080006C40x08000686 4288      CMP      r0,r10x08000688 D000      BEQ      0x0800068C0x0800068A E7FE      B        0x0800068A0x0800068C F000F904  BL.W     GUI__Config (0x08000898)0x08000690 490D      LDR      r1,[pc,#52]  ; @0x080006C80x08000692 202E      MOVS     r0,#0x2E0x08000694 7008      STRB     r0,[r1,#0x00]0x08000696 F000F8F9  BL.W     GUI_X_Init (0x0800088C)0x0800069A 480C      LDR      r0,[pc,#48]  ; @0x080006CC0x0800069C F001FC70  BL.W     0x08001F800x080006A0 F001FF84  BL.W     emWin_LCD_Init (0x080025AC)0x080006A4 4604      MOV      r4,r00x080006A6 2100      MOVS     r1,#0x000x080006A8 4608      MOV      r0,r10x080006AA F000F8A5  BL.W     GUI_SetOrg (0x080007F8)0x080006AE F000FE31  BL.W     WM_Init (0x08001314)0x080006B2 4620      MOV      r0,r4GUI__Config calls LCD_X_Config and GUI_X_Config

[Tesla DeLorean]

Posted on August 01, 2013 at 15:18

If looks like something like if (! a!= b) for(;;) ;

I understand that, but you need to look at the registers during the PRECEDING code, and determine what memory it is touching. Perhaps you can look at the .MAP file, or other linkage information to see what memory it is touching there. The code is more like: a[0] &= ~1; b[2] = 1; c[0] = 0x12345678; if (c[0] != 0x12345678)   while(1); The addresses could be in peripheral space, you'd need to look at the registers. Is it perhaps tied to a specifically licensed STM32 part? Have you tried changing the registers in the debugger so this test succeeds?