STemWin: using GUI_X_Warn() and GUI_X_ErrorOut()

[pertti]

Posted on February 25, 2014 at 16:34

I'm using the STemWin522_CM4_OS_GCC library on a STM32F407 board (our own, testing on a 3240g EVAL).  

 

I have a problem using the precompiled library. It should be possible to define the functions GUI_X_Warn() and GUI_X_ErrorOut() to get error messages. I added code to these in GUI_X_FreeRTOS.c. These seem to be never called.  

I have have had emWin crashes in several places inside the library (usually within GUI_Init() ). And I tried setting the debug level to GUI_DEBUG_LEVEL_LOG_ALL. But never a call to these functions

(or GUI_X_Log()) 

.

To me it seems that the STemWin522_CM4_OS_GCC.a has been compiled with 

&sharpdefine GUI_DEBUG_LEVEL GUI_DEBUG_LEVEL_CHECK_PARA

Then the above functions will not work.

Is there any way to get the emWin error messages? The GUI_Error() function does not get called either. Figuring out what causes a crash inside the binary STemWin library is not working too well without any error messages ...

Pertti 

#stemwin

[Tesla DeLorean]

Posted on February 25, 2014 at 16:41

Use a debugger much?

[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STemWin%20GUI_Init%28%29%20crashed&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=675]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FSTemWin%20GUI_Init%28%29%20crashed&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=675

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/the%20STemWin%20used%20external%20SDRAM%20can%27t%20pass%20the%20GUI_Init&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=99

[pertti]

Posted on February 25, 2014 at 17:18

Those two discussions I had red already earlier. 

I do use debugger a lot. Eclipse+gdb+openocd through a SWD connection. On a Mac so cannot use the simulator.

I have lots of code working, also on the GUI side. But for example now would have liked to see the emWin errors while trying to add emWin Layers. Debugger does not help much without the emWin source code - the only thing I can see what is the name of the function where the code crashes.

Pertti

[Tesla DeLorean]

Posted on February 25, 2014 at 18:48

I've managed to debug several of these problems without source code, and across several oceans.

You're not likely to get source code, so you'll have to work through the failing assembler code and the register values. There are several cases where the code stops in an infinite loop, and registers point explicitly to memory locations with ASCII messages. Suggest you present your failure situations in a manner that would permit analysis.

[pertti]

Posted on February 26, 2014 at 08:21

Thanks Clive. Ok, have to do without those error messages (or buy a license form Segger). I'll look at the registers etc. with a debugger the next time.

Let's see if some of the problems is such that I could extract a small example program to showcase it. Possibly not as I suspect emWin is running out of resources, even though it should have enough memory allocated.

Pertti

[joerg23]

Posted on March 04, 2014 at 23:37

Before

I spend

$ 10,000

for this

half-baked

product

freezes

the

hell.

The editor is

far from everything

.

No

copy

and

paste.

No

grouping

to move, no adjustable grid

and so on.

Segger

should invest

more time

in

the utility

.

Not

in

gimmicks

such as video

images

and the like.

I hardly think

that someone

so

will develop

an MP3

player

or similar with it. If I want something to play with a buy a play station and not that.

And while we

're at it.

Can anyone tell

why

we now have to

change everything

what we have

so far invested

in

programs

to a new

system

driver

?

[jose luu]

Posted on January 01, 2017 at 16:23

NXP is releasing librairies compiled with #define GUI_DEBUG_LEVEL GUI_DEBUG_LEVEL_LOG_ALL

see in this document: 

http://www.nxp.com/assets/documents/data/en/release-notes/EMWIN-RN.pdf

 on page 2

'Library files that include '_d5' are built with GUI_DEBUG_LEVEL=5. Linking with these libraries will cause diagnostic messages for log entries, warnings, and entries to be produced.'

Such a library debug version is what we are asking for, only doable by ST, the benefit to the community of users is that it would lower the first step of an implementation.