STM32F3DISCOVERY: quick start with Mac OS X

Tools needed:

• gcc, binutils
• gdb
• stlink utility

Workflow

Developing and debugging embedded software includes several steps. The first tool you will certainly need is a compiler. Compiler translates the source code written in C/C++ or any other programming language into the codes, that a CPU can understand. In case of STM32, which includes an ARM Cortex-M3 core, the most convenient and reliable compiler is GCC.

GCC, Binutils, GDB

Happily, almost all tools we need (namely, GCC, GDB and binutils) are available via MacPorts. All we need to do is:
sudo port install arm-none-eabi-gcc arm-none-eabi-binutils
After port has finished downloading and unpacking them, a bunch of 'arm-none-eabi-' tools would be accessible via command line.

Installing stlink utility

The last thing we need to start debugging a chip is a debugger adapter. This kind of tool is used as an interface between the GDB debugger and the MCU hardware. There are 2 possibilities: stlink and OpenOCD. OOCD is a more complex tool, which supports a lot of different adapters, like FT2232, STLink, Altera, J-Link, R-Link and others. But we only need an STLink support, so we could go another way, which is a bit simpler and install stlink utility.

sudo port install libusb automake autoconf pkgconfig
aclocal --force -I /opt/local/share/aclocal
git clone https://github.com/texane/stlink.git stlink-utility
cd stlink-utility
./autogen.sh
./configure
make

Now copy st-flash and st-util binaries somewhere else (probably I'll manage to write a Portfile some day to make it available via MacPorts also).

Debug

Run st-util (running it with no parameters is enough in our case). It should produce something like this:

2013-02-12T23:18:04 INFO src/stlink-common.c: Loading device parameters…. 
2013-02-12T23:18:04 INFO src/stlink-common.c: Device connected is: F3 device, id 0x10036422 
2013-02-12T23:18:04 INFO src/stlink-common.c: SRAM size: 0xa000 bytes (40 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes Chip ID is 00000422, Core ID is 2ba01477. 
KARL - should read back as 0x03, not 60 02 00 00 
init watchpoints 
Listening at *:4242…

Now start GDB with remote target:

arm-none-eabi-gdb <compiled ELF firmware file path>
(gdb) tar extended-remote :4242
(gdb) load
Have fun using GDB CLI commands

Also you can use any other GDB fronted you wish: for example Eclipse has one, so it could be configured to debug in-chip.