{"id":994,"date":"2013-03-08T00:00:00","date_gmt":"2013-03-07T23:00:00","guid":{"rendered":"https:\/\/www.fussylogic.co.uk\/blog\/?p=994"},"modified":"2016-05-18T11:34:53","modified_gmt":"2016-05-18T10:34:53","slug":"getting-started-with-the-stm32f0-discovery","status":"publish","type":"post","link":"https:\/\/www.fussylogic.co.uk\/blog\/?p=994","title":{"rendered":"Getting Started With The STM32F0 Discovery"},"content":{"rendered":"

Introduction<\/h2>\n

I\u00e2\u20ac\u2122ve added another nice cheap dev board to my collection, the STM32F0 Discovery<\/a>, which I got from RS in the UK for \u00c2\u00a3. It\u00e2\u20ac\u2122s an SGS Thompson (ST) kit, based around their STMF051R8T6<\/a> device, which is in turn based on an Arm Cortex M0<\/a>.<\/p>\n

I like this sort of dev board so much because they allow you to work on the hardest part of getting going with a new embedded microcontroller, cheaply \u00e2\u20ac\u201c getting the first program compiled, programmed into the device, and running. It\u00e2\u20ac\u2122s hard because you have to piece together all the software components, a dev environment, and some sort of programmer. This is made even harder if you\u00e2\u20ac\u2122re a Linux user, as (for a reason I don\u00e2\u20ac\u2122t understand) chip manufacturers promote closed source, expensive compilers like Keil and IAR over free GCC based systems. They could even use Eclipse if they felt a graphical interface was necessary. C\u00e2\u20ac\u2122est la vie<\/em>. Dev kits for new microcontrollers used to run into the hundreds of pounds, when all you really want is a board with a powersupply, some pins and a header for programming\/debugging. That\u00e2\u20ac\u2122s exactly what these new style dev boards are.<\/p>\n

For a while I was playing around with a similar device\/board from Texas Instruments \u00e2\u20ac\u201c their Stellaris Launchpad board<\/a>, which I chose because I like the MSP430 Launchpad<\/a> board so much \u00e2\u20ac\u201c but as I investigated it seemed like TI have put uncomfortable licenses on a few of their example files, and have made it not straight forward to program from Linux. (I\u00e2\u20ac\u2122m also not very impressed with their attitude to not supporting SDCC\/GCC for their ZigBee and Bluetooth Low Energy software stacks). So, I was pleased to be told about this discovery board from ST (to be fair these two are slightly different, this ST board is a Cortex-M0 device; and the Stellaris Launchpad is a Cortex-M4 device, but there\u00e2\u20ac\u2122s a Cortex-M4 discovery board<\/a> if we outgrow the STM32F0).<\/p>\n

These discovery boards are between \u00c2\u00a35 and \u00c2\u00a310 pounds; and the chips themselves, in one-off prices are just over \u00c2\u00a32 \u00e2\u20ac\u201c very pleasant; and you get a lot of CPU for your buck.<\/p>\n

Enough waffle. On to the meat.<\/p>\n

Programming the flash memory<\/h2>\n

On the board is an STM32 (the product line) F (general purpose) 051 (Cortex-M0, \u00e2\u20ac\u0153051\u00e2\u20ac\u009d range of devices) R (64-pin) 8 (8kB RAM; 64kB flash) T (LQFP) 6 (-40 to 84 working temp). The ST website, has a datasheet (which isn\u00e2\u20ac\u2122t a lot of use) and, more important, the reference manual (all 748 pages) easily downloadable. On the whole: points for ST, I got the data I wanted, and there\u00e2\u20ac\u2122s lots of it.<\/p>\n

Plugging the board in to a USB slot, powers it up and runs the sample program. An LED flasher. Good.<\/p>\n

Make sure you\u00e2\u20ac\u2122ve got access to the USB device, by adding a rule like this to your \/etc\/udev\/rules.d\/<\/code> directory (use lsusb<\/code> to check the vendor and product ids):<\/p>\n

# 51-stm32-discovery.rules\nATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", MODE="0660", GROUP="plugdev"<\/code><\/pre>\n
Reload the rules with \/etc\/init.d\/udev reload<\/code>.<\/p>\n
We can be pretty confident that, being an ARM core, that we\u00e2\u20ac\u2122ll be able to find a compiler for Linux (ARM being everywhere<\/em> now, and the big boy varieties actually run Linux), so our first hurdle is a programmer. Fortunately, some clever chaps have already done the hard work \u00e2\u20ac\u201c openocd<\/a>. Double fortunately, it\u00e2\u20ac\u2122s already in Debian, with STM32F0 discovery support (the power of open source communities).<\/p>\n
OpenOCD is very flexible, and does far more than just what we\u00e2\u20ac\u2122ll use it for, so it can appear complicated, but it\u00e2\u20ac\u2122s just recipes that you can fire and forget after they\u00e2\u20ac\u2122re written. Here\u00e2\u20ac\u2122s my Makefile<\/code> for running OpenOCD:<\/p>\n
# Makefile.ocd\nOPENOCD_SCRIPT_DIR := \/usr\/share\/openocd\/scripts\nBINARY := $(shell pwd)\/$(BINARY)\n\ndefault:\n    @echo "make read BINARY=yourbinary.bin"\n    @echo "make program BINARY=yourbinary.bin"\n\nread:\n    @[ ! -e "$(BINARY)" ] || (echo "$(BINARY) already exists, won't overwrite" && exit 1)\n    openocd \\\n        -f $(OPENOCD_SCRIPT_DIR)\/board\/stm32f0discovery.cfg \\\n        -c "init" \\\n        -c "reset halt" \\\n        -c "sleep 100" \\\n        -c "wait_halt 2" \\\n        -c "dump_image $(BINARY) 0x08000000 65536" \\\n        -c "reset halt" \\\n        -c "shutdown"\n\nprogram: $(BINARY)\n    openocd \\\n        -f $(OPENOCD_SCRIPT_DIR)\/board\/stm32f0discovery.cfg \\\n        -c "init" \\\n        -c "reset halt" \\\n        -c "sleep 100" \\\n        -c "wait_halt 2" \\\n        -c "flash write_image erase $(BINARY) 0x08000000" \\\n        -c "sleep 100" \\\n        -c "verify_image $(BINARY) 0x08000000" \\\n        -c "sleep 100" \\\n        -c "reset halt" \\\n        -c "shutdown"<\/code><\/pre>\n
Our openocd<\/code> command read 65536 bytes starting at device memory address 0x08000000. That address can be seen in the memory map in the reference manual<\/a> as being the address that the internal flash is mapped to. Being a 32-bit CPU, the ARM actually has a 4GB address space \u00e2\u20ac\u201c have a look at the documentation for the specifics.<\/p>\n
A quick aside to talk about how the device is actually programmed. The two jumpers that we had to ensure were connected pass two of the pins through the USB part of the Discovery board (SWDIO on PA13, and SWDCLK on PA14). Those pins are set on reset to use the SWD mode as their alternate function. It probably isn\u00e2\u20ac\u2122t wise, while using the DISCOVERY board to change away from that, as you won\u00e2\u20ac\u2122t be able to debug. If you want those pins for your own application, you may also have to take the jumpers off after programming.<\/p>\n
Inconveniently, USART1<\/code> (as PA9 and PA10) are connected to the USB-interface chip as STLINK_RX<\/code> and STLINK_TX<\/code>, but there is no USB serial port implemented on that interface device. The MSP430 Launchpad has the slight advantage here, the USB part also appears as a USB serial port, and those pins are connected to the device, so you have a ready made debug serial port to communicate with the device \u00e2\u20ac\u201c no such luck on Discovery, you\u00e2\u20ac\u2122ll have to get a USB-TTL serial converter (but they\u00e2\u20ac\u2122re only a couple of pounds on eBay, and no embedded programmer should be without one anyway) then connect to JP1 (after adding solderbridges SB14 and SB15).<\/p>\n
Toolchain<\/h2>\n
Before we can compile our own programs, we\u00e2\u20ac\u2122re going to need a compiler.<\/p>\n
You\u00e2\u20ac\u2122ll want the bare-metal version of the toolchain, arm-none-eabi<\/code>. Code Sourcery (now Mentor Graphics) distribute<\/a> a convenient set of builds for the ARM cross-compiler and toolchain. I believe it will be possible, with a bit of research, to use the arm-linux-eabi<\/code> version, and hence to get the cross-compiler direct from the emdebian<\/em> project. For now though, fill in the annoying \u00e2\u20ac\u0153what\u00e2\u20ac\u2122s your name\u00e2\u20ac\u009d form and download the bare-metal compiler from Mentor.<\/p>\n
I keep mine in \/opt\/<\/code>:<\/p>\n
$ cd \/opt\n$ sudo tar axvf \/home\/user\/download\/arm-2012.09-63-arm-none-eabi-i686-pc-linux-gnu.tar.bz2<\/code><\/pre>\n
My own habit is not to add anything to the path; it\u00e2\u20ac\u2122s easy enough to specify a toolchain prefix in most makefiles, and none of the tools themselves rely on an absolute path, or on being in the system search path, so why bother? Of course, you are welcome to do as you please.<\/p>\n
Compiling<\/h2>\n
Finally, we can start programming. ARM devices are considerably more complicated that the little 8-bit devices I\u00e2\u20ac\u2122ve talked about in the past. This is exacerbated by ARM not actually being a CPU, but rather being a CPU core that other manufacturers customise. This means that no two ARM-based CPUs are the same. That complexity is revealed in three key areas:<\/p>\n