stm32f4 discovery dev board

buildscc | 12 Sep 2012 | | projects


Open Source Toolchain


Under linux this is rather straightforward. I was able to compile with toolchain without a hitch using [ these instructions], under OS X I would imagine its a tad more of a pain in the ass.

The programs/scripts being used are the following:


Thanks to [[Alex Whittemore]] there is some good documentation

[here] on one method of getting set up with Eclipse.

[[Chris Woodall]] would prefer to use emacs + a makefile to do his development, so the methodology is a little different.

First, you should make sure you have XCode installed, because that will install gcc and all of the development tools you need for some of the future steps. Now, lets get [ macports] if you have a Mac and some self respect you should already have macports anyway (or [ homebrew]).

Then we will install the arm-none-eabi toolchain, this might take awhile if you have never used macports before, while you are at it you should install git:

$ sudo port install arm-none-eabi-*
$ sudo port install git # optional

Now we will use git to grab texane’s great [ stlink program]:

$ mkdir ~/src #optional, but my preferred working directory for installations like this
$ cd ~/src # optional
$ git clone
$ cd stlink/gdbserver
$ make

Now we can actually load up an example program! So lets do that:

$ cd ~/src/stlink/examples/blink

Then connect to the debugger and try it out…

$ arm-none-eabi-gdb
(gdb) target remote localhost:4242
(gdb) load blink_F4.elf
(gdb) continue

You should see the Green, Orange, Blue and Red lights blink on and off. If this worked, then great success!

Makefile and Libraries

So I am using a modified version of the standard STM32 libraries. As I go I might start rewriting parts of the STM32F4 library code for myself. However, at the moment I am use the peripheral access provided by ST.

The library along with some boilerplate template code can be found on [ github (thanks to prattmic)]. I needed to change some CFLAG variables in the Makefile and a few compiler directives in the file ‘'’startup_stm32f4xx.s’’’.

All of these altercations are due to the fact that our compiler wasn’t compiled with support for the hardware FPU. LINK TO MY VERSION COMING SOON.

Older · View Archive (146)

Meeting Minutes for 2012-09-12


This is the First Meeting

Officers introduced themselves

New and current members raise hand for interest areas

- mechanical, biomedical, electrical, computer engineering, programming
- rockets, robots, sound systems, arduino hacking,
- video game programming, graphics, network security, app development
- lockpicking

Introduction to builds

  • builds is the place for you to learn that. we exist to facilitate learning, especially through collaboration. the way builds works:
    • meetings: weekly, wednesdays, 6:30. everyone gets together to talk about events and current projects. this meeting not representative, more like an orientation.
    • events: hackathon, indiegamefest, hackny, csaw
    • the room: open 24/7. if you stick around, we’ll give you swipe access; right now the door will always be unlocked. come in and work in between classes, stop by to check out the tools. After classes end we can use power tools, so on any given night you’ll find people in here working. we also are going to start unlocking classrooms next door to use as middle of the night homework hubs.
    • projects: if you have a project, you can propose it. first of all you just pitch it to the group at a meeting to see general interest. if it’s cheap, doesn’t need a lot of people, cool, start working on it right away– if it’s big, we require you to submit a project proposal (which is great for learning how to write design docs) to the officers to review, get funding, etc. then becomes project w/ weekly meeting times etc. time at the end for new pitches.

Projects for the meeting:

  • Video Game Collective
  • CSAW
  • BUILDSbot
  • Multitouch


  • VGC
    • level 1: no game programming experience: Gamesalad
    • Level 2: pygame
    • Level 3: c++ w/ john & jeff
  • BUILDSbot meeting :
    • project planning
    • design docs


Virtual Machines

We are running all virtual machines on builds-ashitaka.

Here are the steps that we took while setting them up.

—- The VMs are being managed by ‘virt-manager’ Any user that wants to be able to see and configure VMs must be in the group ‘libvirt’, and then can run ‘virt-manager’. Networking is running BRIDGED. So, we have a bridge device, br0, that both ashitaka and all of its VMs connect to.

Externally, it looks like ashitaka is a switch, that ashitaka and all of its VMs hide behind. The configuration for this is as follows.

On ashitaka, /etc/network/interfaces was modified as follows:

auto br0 iface br0 inet static address gateway netmask bridge_ports eth0 bridge_stp on bridge_maxwait 0 bridge_fd 0

In virt-manager, we set up a network called ‘bridge’, which has some pretty logical setup involving bridging.

—- For Linux VM’s to be able to resolve DNS add the following to /etc/resolv.conf:

domain search nameserver nameserver nameserver