2014-02-25 07:34 AM
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 #stemwin2014-02-25 07:41 AM
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¤tviews=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=6752014-02-25 08:18 AM
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
2014-02-25 09:48 AM
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.2014-02-25 11:21 PM
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.Pertti2014-03-04 02:37 PM
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 gridand 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
?
2016-01-01 07:23 AM
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.