Jump to content

STM32F7 Discovery


Joel Bodenmann

Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...

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 by tctippens
Link to comment
Share on other sites

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?

 

 

Link to comment
Share on other sites

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 by BenjyC
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...