More STM32 MBED Development Environment

For 2 months I have been switching back and forth between using mbed.com online, eclipse with gcc4mbed, gcc4mbed with geany and just gcc4mbed in a terminal with the makefile and vi.

Mbed on-line is expensive and very slow. I have had access as long as the cell company keeps the towers working, but not always. Also, mbed.com does not support the DISCOVERY boards on-line. The code is there, but I can't select a non-'mbed platform' for the compiler when i start a new program. When the internet access is fast, it is easy to exercise demo code there.

I really should give the eclipse CDT another shot. While I was trying simple programs in single files, it seemed OK. But when I got a little more comlplex it seemed to get unstable and not repeatable. Everything would be fine one day,then the next it could no longer find the libraries to compile the last copy of the file from the day before. I was having a lot of issues then and some may have been self induced.

Anyway I learned how to get the gcc4mbed setup to work directly. It did not support any of the STM32 boards at first though. I managed to modify the main makefile for the NUCLEOF401RE board (as in this post). Then every thing was fine for a while.

Until I decided to try the RTOS real-time extensions. Then it became obvious that I missed something in the special board-device-mk makefile. About the same time, the author of gcc4mbed decided to update it to the newer rev. 92 of the mbed source. He asked me to rerun some of the tests on my boards to verify his changes.

Everything stopped working. A coupe weeks of reading forums and Google searches, I made some changes, verified lots of code and thought it was ready again. After submitting them, It turns out I missed one more, but I think we have it fixed now.

# Vendor/device for which the library should be built.
MBED_DEVICE        := NUCLEO_F401RE
MBED_TARGET        := STM_NUCLEO_F401RE
MBED_CLEAN         := $(MBED_DEVICE)-MBED-clean

# Compiler flags which are specifc to this device.
TARGETS_FOR_DEVICE := TARGET_NUCLEO_F401RE TARGET_M4 TARGET_CORTEX_M TARGET_STM 
TARGET_STM32F4 TARGET_STM32F401RE
TARGETS_FOR_DEVICE += TARGET_FF_ARDUINO TARGET_FF_MORPHO
GCC_DEFINES := $(patsubst %,-D%,$(TARGETS_FOR_DEVICE))
GCC_DEFINES += -D__CORTEX_M4 -DARM_MATH_CM4 -D__FPU_PRESENT=1

C_FLAGS   := -mcpu=cortex-m4 -mthumb -mthumb-interwork -mfpu=fpv4-sp-d16 -mfloat
-abi=softfp
ASM_FLAGS := -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp
LD_FLAGS  := -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp


# Extra platform specific object files to link into file binary.
DEVICE_OBJECTS :=


# Linker script to be used.  Indicates what code should be placed where in memor
y.
LSCRIPT=$(GCC4MBED_DIR)/external/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TA
RGET_STM32F4/TARGET_NUCLEO_F401RE/TOOLCHAIN_GCC_ARM/NUCLEO_F401RE.ld


include $(GCC4MBED_DIR)/build/device-common.mk

Turns out the options for the floating point hardware, needed by the RTOS, needed to be applied constantly to each of the _FLAGS lines. If not, the linker would link a mixed set of libraries and the resulting code would hang in various places.

 So I now have a setup that at least is reliable.  I am using geany, a text editor using the GTK2 toolkit with basic features of an integrated development environment, with the special makefiles from gcc4mbed.