STM32F7 Discovery

[BenjyC]

Thanks very much for your support, I've finally built the project and got it running on my device. In summary, After using cygwins version of mkdir my steps to compile your bitbucket project on eclipse were:

Add the following inclusions to the project as CShark said:

[ugfx root directory]
${ProjDirPath}\STM32F7xx_HAL_Driver\Inc}
${ProjDirPath}\

Edit the Makefile to replace HAL to STMHAL, and add a path as vlad said:

INCPATH  = $(STMHAL)/Inc

Change ugfx/tools/gmake_scripts/cpu_stm32m7.mk so that:

SRCFLAGS += -mcpu=cortex-m7 -falign-functions=16 -mfloat-abi=hard -mfpu=fpv5-sp-d16 -fsingle-precision-constant
LDFLAGS  += -mcpu=cortex-m7 -falign-functions=16 -mfloat-abi=hard -mfpu=fpv5-sp-d16 -fsingle-precision-constant

[inmarket]

Adding the _sbrk routine is not the best way to handle that missing symbol. In fact it incorrectly allocates an area that might be non-contiguous with previous allocations.

The _sbrk symbol becomes undefined when a routine (often in the c runtime library) calls malloc.

The correct way to fix this problem is to define the GFX_EMULATE_MALLOC define in your gfxconf.h. Thats causes ugfx to create its own malloc and free calls which stops the missing references the correct way.

[Joel Bodenmann]

The correct way to fix this problem is to define the GFX_EMULATE_MALLOC define in your gfxconf.h. Thats causes ugfx to create its own malloc and free calls which stops the missing references the correct way.

More information on this can be found here: http://wiki.ugfx.org/index.php/GOS#Emulating_Malloc

~ Tectu

[CShark]

I would like to use GFX_EMULATE_MALLOC, but it does not resolve the linker error with a missing _sbrk definition. Namely, I'm using the function snprintf from stdio.

[inmarket]

The reason is that snprintf is pulling in the full fileio interface.

Not only is this huge (both code and ram), it also causes these sorts of strange errors.

It is probably a good idea to replace snprintf with the ugfx library equivalent snprintg from the GFILE module. The implementation is much smaller and will resolve these dorts of link errors.

If studio is adding calls to snprintf then please list this as a bug in the studio forum.

[Joel Bodenmann]

It is probably a good idea to replace snprintf with the ugfx library equivalent snprintg from the GFILE module. The implementation is much smaller and will resolve these dorts of link errors.

More information about this can be found here: http://wiki.ugfx.org/index.php/GFILE#STDIO_emulation

~ Tectu

[tctippens]

Joel,

Is the example project you provided earlier in this thread still available? I have not been able to find it after the switch to "community.ugfx.org" took place a few days ago. It does not appear to be attached to your earlier post now.

[tctippens]

Sorry for all the duplicate posts. I kept getting an error when I tried to submit it the first time and I didn't think it went through.

[tctippens]

I believe I have applied all of the suggestions recommended in this thread, but I am not sure how to use cygwin's mkdir in Eclipse. I keep getting errors saying "recipe for target 'build/obj/../uGFX/src/gfx.o' failed", and that "Program "gcc" not found in PATH".

 

 

Edited February 14, 2016 by tctippens

[tctippens]

I have followed the steps in the previous post and am getting the following error:

Compiling STM32F7xx_HAL_Driver/Src/stm32f7xx_hal.c
arm-none-eabi-gcc.exe: error: unrecognized argument in option '-mcpu=cortex-m7'
arm-none-eabi-gcc.exe: note: valid arguments to '-mcpu=' are: arm1020e arm1020t arm1022e arm1026ej-s arm10e arm10tdmi arm1136j-s arm1136jf-s arm1156t2-s arm1156t2f-s arm1176jz-s arm1176jzf-s arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm70 arm700 arm700i arm710 arm7100 arm710c arm710t arm720 arm720t arm740t arm7500 arm7500fe arm7d arm7di arm7dm arm7dmi arm7m arm7tdmi arm7tdmi-s arm8 arm810 arm9 arm920 arm920t arm922t arm926ej-s arm940t arm946e-s arm966e-s arm968e-s arm9e arm9tdmi cortex-a15 cortex-a5 cortex-a7 cortex-a8 cortex-a9 cortex-m0 cortex-m1 cortex-m3 cortex-m4 cortex-r4 cortex-r4f cortex-r5 ep9312 fa526 fa606te fa626 fa626te fa726te fmp626 generic-armv7-a iwmmxt iwmmxt2 mpcore mpcorenovfp native strongarm strongarm110 strongarm1100 strongarm1110 xscale
make: *** [build/obj/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal.o] Error 1
 

This seems to be set in the Makefile included in the zipped project above:

# MCU flags
MCUFLAGS      = -mthumb -mcpu=cortex-m7

 

Does this need to be changed or am I missing something?

 

 

[Joel Bodenmann]

It seems like the toolchain that you are using doesn't provide support for the Cortex-M7 architecture. You might need to update to a more recent version of GCC.
I think that you need to get at least 4.9.3 for Cortex-M7 support.

[tctippens]

To clarify, does this refer to the GNU Tools ARM Embedded download mentioned by CShark? Or to cygwin?

[Joel Bodenmann]

The GNU ARM tools. Most people use this: https://launchpad.net/gcc-arm-embedded

[inmarket]

Don't forget to set your PATH variable so that the new compiler is included before the one that comes with cygwin.

[BenjyC]

For the gdisp drivers, gdisp_lld_STM32LTDC.c contains an error on line 383, should read:

DMA2D->OPFCCR = OPFCCR_RGB888;

That said, trying to switch to RGB888 just displays a black screen on the STM32F7-DISCO, is this supported?

Edited February 17, 2016 by BenjyC

[inmarket]

This typo has now been fixed in the repository.

With regard to the black screen...

The RGB888 code was originally written for the STM32F426-iDiscovery board and at that point it worked. That code has been replicated into the generic STM32LTDC driver, updated for the F7 and then remerged with the F4 code. In that time it hasn't been retested in RGB888 mode so it is quite possible that it never worked for the F7 and we might also have broken it for the F4.

Any help you can give us in finding and fixing the problem would be appreciated.

[tctippens]

I have upgraded my toolchain from GNU Tools ARM Embedded 4.9.3 to GNU Tools ARM Embedded 5.2.4. I edited the PATH in Eclipse to first list the GNU toolchain and then Cygwin. I am still getting the following errors:

Program "gcc" not found in PATH

Program "g++" not found in PATH

Eclipse says these errors are a "C/C++ Scanner Discovery Problem" and points me to the location "Project Properties, C++ Preprocessor Include/Providers, [CDT GCC Built-in Compiler Settings] options". 

This is the same error that I had before with the 4.9.3 toolchain in Eclipse. For some reason when I try to compile in the Cygwin terminal, I get the other error of not recognizing cortex-m7.