STM32F4 Discovery open-source development software

Hi Tim,

I'm interested in what you have done here with the open source toolchain.

I'll be working on getting it all going with CoIDE and gcc-arm-none-eabi-4_7 (as soon as I get some free time) so any pointers you may have would be very helpfull.

I've got an application in mind for driving Variable Message Signs and need to get the ethernet interface working along with the GLCD and touch screen.

Regards,

Dean.

Well there was a lot of learning curve because I never worte makefiles before, although I've used Linux a lot. 

Obviously you need to collect a list of all the source files you need in your project, you can use $wildcard, but sometimes that gets conflicting alternates etc.  For gcc working bare-metal you need a .specs file that adds libnosys.a to the lib variable so that system calls from within libc (eg _sbrk) get satisfied. 

You need gcc options -mthumb and -mcpu=cortex-M4 (or what have you), plus the options for floating point if you use it, that selects which library gets used.  Beware that the default is ARM assembler, which the cortex-M series can't read, and attempting to interwork will get you a hard-fault exception.  Make sure everything is compiled for thumb code, and that all functions in the map have odd-numbered addresses (bit 0 set identifies thumb code). Add "-D USE_STDPERIPH_DRIVER" unless you are talking direct to registers.

Don't call ld directly, always use the gcc wrapper, it adds the core libraries.  Then you need a startup file and an ld script that martch each other, i.e. the startup uses the same section names that the script defines, and of course you need to put the right memory definitions in the ld script, the examples come with mem.lc and sections.ld separately.  I used the default startup then found the gcc/ride .ld didn't match it, and modified it to fit.   Probably you could use either of the supplied toochain option versions instead with little effort, it should only be a matter of what labels they use for start and end of initialised RAM etc.

Most of the examples don't include a stm32f4xx_conf.h file, which selects which standard preipheral headers to include, but it's pretty harmless to use the default one that includes everything.

For some reason discovery_lcd.c #includes fonts.c rather than fonts.h, which means wildcard compilation gets fonts.o twice, either exlude fonts.o or fix the code.

The debug and lcd-log (printf/stdio output to UART or LCD respectively) functions don't work out of the box, the "PUTCHAR" function they actually need to supply for newlib is "int _write( FILE*fd, char*pc, int len){}", and not either of the options they give (and note that needs to output the whole buffer, not just a char).  Obviously you can only include one or the other of the above in your link.

Debugging: you need to build openocd with config options --enable-hla and --enable-stlink, install it, then plug in the Discovery board and run it  with a config file (./openocd.cfg) as follows:

interface hla

hla_layout stlink

hla_vid_pid 0x0483 0x3748

stlink_api 2

source [find target/stm32f4x_stlink.cfg]

If you run it in a terminal it's easier to evict if it crashes, but it can be run as a daemon.

Download the manual separately from sourceforge, the one in the distro is out of date and doesn't mention SWD.

Then to talk to it run (in a separate termnal)

arm-none-eabi-gdb -ex 'target remote :3333' filename

and start typing commands like

load filename

monitor reset halt

cont

or whatever.

I've posted this a few times. Here is a great resource for getting STM32 dev going under linux. And he's got great examples.

http://www.cs.indiana.edu/~geobrown/book.pdf

Mike

Yes, a very useful training resource, gives helpful examples of makefiles, linker scripts etc, but it is based on the Discovery VL board so doesn't cover ethernet, USB, fpu or other features of the STM32F4 Discovery kit, or the ramifications of using the ST supplied code and examples with gcc. Software developers might find his concentration on hardware hacking a bit daunting, but fear not, the F4 kit is a lot more of a 'plug and play' system than the VL or L1 boards.

The great thing about the STM32F4 Discovery kit is that you can get a project started very quickly using or adapting the supplied building bricks without having to delve too far into the details of the hardware, but still having access all the way to bare metal.  You only have to hack the bits you are interested in using, which takes a lot of the steepness out of the traditional development system learning curve.  With a 1300 page hardware reference manual, 250 page programming manual and 180 page data sheet to learn just for the chip itself, we need all the help we can get.

Tim

Running on Ubuntu 12.04 ...

So far I've built the summon tool chain (pretty straightforward) git clone the repo, cd to it and run the script.

This puts all of the tools you need in ~/sat/bin which you can set your tool root too.

The challenge for building bare metal code is that you need a linker script, some initial startup code and the register definitions.

I pulled the stm32f4xx.h file from the ST distribution. I modified the startup_stm32f4xx.s to pull out everything I didn't really need

and then set up the system clock in my code. It can complile, link, and create a .hex file which the ST tools will flash on the board.

I've got OpenOCD but for reasons that are a bit mysterious, Virtualbox won't let me connect the ST-Link to the my running instance

of Ubuntu. I'll be able to figure that out once I move to a full on system (currently hosting a virtual environment so that I can use windows

to run the STLink software from ST, thus minimizing the number of problems to solve at once.)

My goal is to have a very clean, open source only toolchain, setup so that I can build code for this chip reliably. Then I'll add the Atmel SAM4 series.

--Chuck

I hust got OpenOCD running on the STM32L discovery board as well.  There is a bug in the stm32lx.cfg driver.  My Discovery board has a C-suffix (256k) chip. For this and larger chips, the Flash Size parameter (F_SIZE) is moved from 0x1FF8004C to 0x1FF800CC, and OpenOCD has yet to catch up.  As a workround you can either patch the script or patch the driver (src/flash/nor/stm32lx.c) and rebuild. The config line required is

flash bank $_FLASHNAME stm32lx 0x08000000 0x00040000 0 0 $_TARGETNAME

Also it struggles to connect, talking to the debug port while the processor is running seems to cause problems, I always have to halt the processor before loading else I get errors (this appleis to the F4 as well as the L).  Sometimes it won't connect unless I hold down the reset button while OpenOCD reads the parameters.

Tim

Glad you got it working Tim! I'm doing things a bit differently, I've got a Black Magic Mini (http://www.blacksphere.co.nz/main/blackmagic) which basically has GDB inside of it, so you (in theory, the test will be wednesday when my cable arrives) attach this to the SWD lines, connect the USB port to your machine, poof! it shows up as a serial port, you start up GDB and connect to it. From that point on you just load in the software to test and go.

I put up my simple blink script (https://github.com/ChuckM/minimal-blink) but have switched to using libopencm3 as a base. Currently working on FSMC support (its not in the library yet so I'm adding my take on it) and then to get the LCD running (which uses the FSMC to interface). Currently things hang in the FSMC setup stuff so that will be my next debugging step.

At some point I hope to have a simple LCD graphics library for this thing too.

--Chuck