Programming the STM32F4 DISCOVERY with the Bus Blaster

In my last post I talked about how to set up a toolchain on OSX. In this post I will show you how to program and debug the Discovery board using open source hardware and software.

The Discovery board supports ARM’s new two wire SWD serial debug port and 6 wire JTAG port. ST provides programmers and software to program their chip, but as usual no Linux support. Their dev boards also include a USB to JTAG translator called ST-LINK which has Linux support thanks to texane over at github. There has been discussion there about adding support for the STM32F4 and it appears one fork has been made for this purpose. At this point support seems spotty and programming takes longer than it should so I’ll show you the alternative.

Bus Blaster and OpenOCD
Warning: OpenOCD does not fully support the CortexM4 yet and this method may damage your hardware. I am not an expert OpenOCD user. Use at your own risk.

The Bus Blaster is an open hardware JTAG debugger made by Dangerous Prototypes, which you can get for about $35 at SeeedStudio. Any debugger compatible with Open On-Chip Debugger (OpenOCD) should work fine for these instructions.

Download OpenOCD version 0.5.0 here.
Extract and run the following configure script. You may want to change your install directory.

cd [OpenOCD]
CC=/usr/bin/gcc-4.2 CPP=/usr/bin/cpp-4.2 CXX=/usr/bin/g++-4.2 LD=/usr/bin/ld ./configure --prefix=/opt/local/ --enable-ft2232_libftdi
sudo make install

Download the STM32F4 Demo
Update: You will have to change LDFLAGS, CC, LD, … in the makefile to reflect your system.

git clone
cd STM32F4-Discovery_FW_V1.0.1/Project/IO_Toggle
Connect all 6 JTAG pins from the Bus Blaster to the Discovery. The Bus Blaster has labels on the PCB.
JTAG pinout Discovery board
TDI is located on pin PA15 on header P2 of the Discovery board.
Plugin the Bus Blaster to your computer. Power the Discover board via the mini USB, but NOT using a computer. The computer may cause unwanted signals sent through the JTAG pins.

Unload any FTDI kernel modules so they don’t conflict with OpenOCD

sudo kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext/

Run OpenOCD

cd STM32F4-Discovery_FW_V1.0.1/openocd_config
openocd -f openocd.cfg -f stm32f4x.cfg

You should see something like this

Open On-Chip Debugger 0.5.0 (2011-10-30-17:32)
Licensed under GNU GPL v2
For bug reports, read
Info : only one transport option; autoselect 'jtag'
2000 kHz
2000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : max TCK change to: 30000 kHz
Info : clock speed 2000 kHz
Info : JTAG tap: stm32f4xxx.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4xxx.cpu: hardware has 6 breakpoints, 4 watchpoints

1 Tap is for the CPU and the other is for the floating point unit.

Programming and Debugging with GDB
With OpenOCD waiting for commands open another terminal and run GDB for arm. All commands use the ocd directory as their working directory.

(gdb) target extended localhost:3333
(gdb) # reset and halt the chip
(gdb) monitor halt
(gdb) # load symbol files
(gdb) file demo.elf
(gdb) # load demo.elf into RAM
(gdb) load demo.elf
Loading section .isr_vector, size 0x188 lma 0x8000000
Loading section .text, size 0xc5c lma 0x8000188
Loading section .data, size 0x38 lma 0x8000de4
Start address 0x8000d6c, load size 3612
Transfer rate: 6 KB/sec, 1204 bytes/write.
(gdb) # run the program. hit Control-C to stop
(gdb) continue

(gdb) # run your favorite gdb commands
(gdb) br main.c:71
(gdb) continue
(gdb) list
(gdb) info registers

Writing to flash
So far we’ve only copied our code to SRAM so when the chip is reset the program no longer exists. To write our program to flash we will need to us the flash write_image command, which you can learn more about here.

In GDB the monitor command passes commands straight to OpenOCD. Make sure OpenOCD is running and start GDB.

(gdb) target extended localhost:3333
(gdb) monitor halt
(gdb) file demo.elf
(gdb) monitor flash write_image erase demo.hex 0 ihex
(gdb) continue

This works with the demonstration hex file provided by ST, but I haven’t gotten it working with my build system. My guess is a problem with the linker script.

It seems to get stuck in  HardFault_Handler() at stm32f4xx_it.c:61. If you have any ideas let me know in the comments.

What needs to be done

  1. Figure out the flash problem
  2. Add full support for the STM32F4 in OpenOCD

One Comment

  1. […] Check out the new post on programming with […]



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s