Linker problem: undefined reference to `_sbrk'

[Peter B]

I've just started to get acquainted with µGFX and the STM32F7-discovery board.

I'm using EmBitz 0.42 and gcc on windows for the software development.

At first I tested the demo made by Tetcu (downloadable from Bitbucket): "Tectu-stm32f7-discovery" - Took a while before I succeeded in compiling the demo.

Had to change the "-mfpu=fpv4-sp-d16" defined in cpu_stm32m7.mk to "-mfpu=fpv5-sp-d16", as described by vlad in "STM32F7 Discovery" in the Hardware forum.

Then I used uGFX_studio to develop my own GUI and overwrote the respective files in Tetcu's project with the ones produced by studio.

But now the linker failed: " c:/program files (x86)/embitz/0.42/share/em_armgcc/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/lib/armv7e-m/fpu\libc.a(lib_a-sbrkr.o): In function `_sbrk_r':

sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk' "

Searching the internet gave various solutions - none of them very attarctive - except this: http://stackoverflow.com/questions/1323 ... ng-eclipse

Adding "libnosys.a ( * )" to the "/* Remove information from the standard libraries */" part of " \ugfx_library\boards\base\STM32F746-Discovery\stm32f746nghx_flash.ld " fixed the problem:

/* Remove information from the standard libraries */

/DISCARD/ :

{

libc.a ( * )

libm.a ( * )

libgcc.a ( * )

libnosys.a ( * )

}

Hope this can be helpful for some of you...

Thanks for all your efforts developing these tools..

Merry Xmas / Peter

[Joel Bodenmann]

Hello Peter and welcome to the community!

Thank you very much for sharing your experience. This will definitely be helpful to others.

_sbrk_r() is a system call that's used for memory allocation/management. Usually this isn't something you would find on a microcontroller. It's either implemented in the underlying system that you're using or you simply shouldn't use it. I suspect that the µGFX-Studio project you are using generated a configuration file that enabled one of the file systems in the GFILE section. This has been an issue before but it was fixed a couple of updates before.

Can you please let us know which version of the µGFX-Studio you are using and update to the most recent one? Version 0.12 was released two days ago and it contains many bug fixes.

Now that I am writing this... is it possible that your configuration sets GFX_OS_HEAP_SIZE to 0? In that case the µGFX library would try to use malloc() and free() which would be supplied by your standard clib which call _sbrk_r(). More information on this can be found here: http://wiki.ugfx.org/index.php?title=Ba ... Management

It would also be helpful if you could upload a ZIP archive of your µGFX-Studio project so we can look at both the configuration and the generated files. I'm pretty sure that something is enabled that shouldn't be.

~ Tectu

[inmarket]

The missing _sbrk symbol is an indication that malloc has been called by something. For example using the C runtime library rand () call will use malloc when using the gcc library.

As these routines actually require malloc to work setting a stub symbol for _sbrk is not enough.

If you have performed the checks above as per Tectu's post and the problem remains, you can define the symbol GFX_EMULATE_MALLOC as TRUE in your gfxconf.h (I think that is what it is called). This will cause stub replacement routines to be added for malloc and free using the gfx allocator.

[Peter B]

Thanks both of you for your fast answers,

1) I'm already using studio version 0.12.

2) Studio is enabling ROMFS - cause I'm including a page with a GIF.

3) Included "#define GFX_EMULATE_MALLOC TRUE" in my gfxconf.h - but got this warning plus the linker failure:

#warning "GOS: Cannot emulate malloc as gfxAlloc() internally uses malloc on this platform"

4) I did not define GFX_OS_HEAP_SIZE. Including #define GFX_OS_HEAP_SIZE 20000 in gfxconf.h did the trick - linking is now successful.

I have uploaded the requested ZIP for your reference.

Here you can also see some graphical artifacts in the preview (I'm using the latest uGFX-library files downloaded from repository):

1) Rounded buttons have problems with the corners (I made the background color white to make it more visible).

2) Blending colors are not implemented for rounded buttons (You know that of course).

3) Blending works on square buttons, but overwrites the upper and the left border of the button.

4) The "DejaVu Sans 32 Anti-aliased" substituting font, used in the design window of studio, is smaller than the real thing.

Merry Xmas / Peter

test.zip

[Joel Bodenmann]

I think we should set the default value of GFX_OS_HEAP_SIZE to a non-zero value to prevent confusion in the future...

A couple of remarks:

1) Using a rectangle in the background designer to 'change the background color' is NOT recommended. This is what widget styles are there for. You can create as many widget styles as you like using the WidgetStyle-Manager that you can find in the 'Tools' menu.

2) The missing pixels you are experiencing with the rounder corner buttons are actually rounding issues that are not easy to handle. Inmarket and I have discussed that a couple of days ago and we didn't come to a definitive conclusion on how to fix that so far.

3) The top and left border of the square buttons are not over overwritten - they simply don't exist. The default render implementation of the buttons only draws two lines (you guessed it: at the right and the bottom edge) in hopes of making it look more appealing. Line 205 and 206: https://bitbucket.org/Tectu/ugfx/src/4b ... tton.c-168

4) Matching the fonts is currently one of the biggest issues we are experiencing with the Studio. We will try to improve that for the next release(s).

Thank you for your feedback.

~ Tectu

[Peter B]

Thanks for your reply Tectu.

Using a rectangle in the background designer to 'change the background color' is NOT recommended. This is what widget styles are there for. You can create as many widget styles as you like using the WidgetStyle-Manager that you can find in the 'Tools' menu.

Do you mean that I should apply a Container, covering the whole display, as the basis of each display page? (

/Peter B

[inmarket]

Each display page is already a container.

[Peter B]

Maybe I'm being blind here, but I can't find any ways to apply a WidgetStyle to the background of a page.

In the previous uploaded test example:

1) Selected "none" as Parent for all my Widgets placed directly on the Display Pages.

2) Removed all the rectangle-based backgrounds.

3) The only widgetstyles I can change is for the placed widgets (Containers, buttons and label) - none of them will change the background color.

What am I missing?

/Peter B

[Joel Bodenmann]

You want to change the 'Default Widget Style' of the GWIN Module. You can do that under Settings -> GWIN -> Default Style.

The background property in the widget style only applies to the background of the display - not the widgets themselves.

More information on widget styles can be found here: http://wiki.ugfx.org/index.php?title=Wi ... dget_Style

I guess the uGFX-Studio seems to work reliably enough to start working on documentation now... what do you guys think? There's literally not a single line of documentation so far.

~ Tectu

[Peter B]

I had been there without success...

What confused me was the the "Background color" line under "Settings - GWIN - defaults" - Changing this didn't work.

Changing "Settings - GWIN - defaults - style" works

Regarding documentation:

Your studio is pretty straightforward to use, so one or two examples demonstrating the intended workflow would be enough at this point.

I think it's better you spend your efforts in finishing the tool - so everything is implemented and works as planned.

You should consider to move our last conversations to another subject...

Thanks / Peter B

Edited December 28, 2015 by Guest

[Joel Bodenmann]

Glad to hear that you got it working.

I guess we'll make one or two short videos where we create a project from scratch to demonstrate the intended workflow as per your suggestion.

~ Tectu