Here are my ongoing notes for getting a few things working with 32-bit ARM Cortex-M4 microcontrollers. It’s complicated because there seem to be 5 ways to do everything, and a complicated web of semi-outdated or too-specific tutorials online. This is my contribution to that trend…
I’m trying to get things working on an ST F3 discovery board. Most of the steps should generalize, but I haven’t gone through and verified it. In particular, the makefiles I’ll link below haven’t been simplified for easy switching across processor types (though in principle that’s no problem).
I’m working on an Ubuntu 12.04 system with a bunch of standard development packages already installed, so it’s possible I missed install instructions for some prerequisites.
There are a lot of commercial development environments on Windows, and a few of them might have free trial editions. On Linux, popular options are the CodeSourcery package, which is somewhat limited but might be easier to get working. Another choice is the gcc-arm toolkit, and you can find old scripts to get and build the toolchain from scratch. A better option is to use the prebuilt binaries at this Ubuntu PPA:
$ sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded $ sudo apt-get update $ sudo apt-get install gcc-arm-none-eabi
Now you have arm-none-eabi-gcc ready to go.
I downloaded the firmware example package from ST, specific to the F3 Discovery board.
$ wget http://www.st.com/st-web-ui/static/active/en/st_prod_software_internet/resource/technical/software/firmware/stm32f3discovery_fw.zip $ unzip stm32f3discovery_fw.zip
They have nice project files for a bunch of Windows IDEs, but that’s not as useful to us here.
I hacked up a makefile I found from another source to use the newly-installed gcc-arm binaries and link in the required source files for the USB_Example project. You can skim the XML in the MDK-ARM/USB_Example.uvproj file to see what the include directories and linked source files should be, but that’s kind of a pain.
Here’s the makefile that should go in the Project/Peripheral_Examples/USB_Example directory (paths are relative to it being there, alas). It’s not really optimized since I don’t know enough about their libraries. There’s a lot of extra stuff in this example because it’s bringing in their USB and accelerometer interface libraries as well.
TARGET:=USB_Example TOOLCHAIN_PREFIX:=arm-none-eabi OPTLVL:=3 # Optimization level, can be [0, 1, 2, 3, s]. PROJECT_NAME:=$(notdir $(lastword $(CURDIR))) TOP:=$(shell readlink -f "../../..") DISCOVERY:=$(TOP)/Utilities/STM32F3_Discovery STMLIB:=$(TOP)/Libraries STD_PERIPH:=$(STMLIB)/STM32F30x_StdPeriph_Driver STARTUP:=$(STMLIB)/CMSIS/Device/ST/STM32F30x/Source/Templates/gcc_ride7 LINKER_SCRIPT=$(CURDIR)/TrueSTUDIO/USB/STM32_FLASH.ld INCLUDE=-I$(CURDIR) INCLUDE+=-I$(STMLIB)/CMSIS/Include INCLUDE+=-I$(STMLIB)/CMSIS/Device/ST/STM32F30x/Include INCLUDE+=-I$(STMLIB)/STM32_USB-FS-Device_Driver/inc INCLUDE+=-I$(STD_PERIPH)/inc INCLUDE+=-I$(DISCOVERY) # vpath is used so object files are written to the current directory instead # of the same directory as their source files vpath %.c $(DISCOVERY) $(STD_PERIPH)/src vpath %.s $(STARTUP) ASRC=startup_stm32f30x.s # Project Source Files SRC=stm32f30x_it.c SRC+=system_stm32f30x.c SRC+=main.c # Discovery Source Files SRC+=stm32f3_discovery.c # Standard Peripheral Source Files SRC+=hw_config.c SRC+=usb_desc.c SRC+=usb_endp.c SRC+=usb_istr.c SRC+=usb_prop.c SRC+=usb_pwr.c SRC+=$(wildcard $(STMLIB)/STM32_USB-FS-Device_Driver/src/*.c) SRC+=$(wildcard $(STD_PERIPH)/src/*.c) SRC+=$(DISCOVERY)/stm32f3_discovery_lsm303dlhc.c CDEFS=-DSTM32F30X CDEFS+=-DUSE_STDPERIPH_DRIVER MCUFLAGS=-mcpu=cortex-m4 -mthumb CFLAGS=$(COMMONFLAGS) $(MCUFLAGS) $(INCLUDE) $(CDEFS) LDLIBS= LDFLAGS=$(COMMONFLAGS) -fno-exceptions -ffunction-sections -fdata-sections \ -nostartfiles -Wl,--gc-sections,-T$(LINKER_SCRIPT) ##### OBJ = $(SRC:%.c=%.o) $(ASRC:%.s=%.o) CC=$(TOOLCHAIN_PREFIX)-gcc LD=$(TOOLCHAIN_PREFIX)-gcc OBJCOPY=$(TOOLCHAIN_PREFIX)-objcopy AS=$(TOOLCHAIN_PREFIX)-as AR=$(TOOLCHAIN_PREFIX)-ar GDB=$(TOOLCHAIN_PREFIX)-gdb all: $(OBJ) $(CC) -o $(TARGET).elf $(LDFLAGS) $(OBJ) $(LDLIBS) $(OBJCOPY) -O ihex $(TARGET).elf $(TARGET).hex $(OBJCOPY) -O binary $(TARGET).elf $(TARGET).bin .PHONY: clean clean: rm -f $(OBJ) rm -f $(TARGET).elf rm -f $(TARGET).hex rm -f $(TARGET).bin
You should be able to build everything now and get the binary, USB_Example.bin.
Flashing the board
Again, there are several options. The easiest is probably the nice USB interface that comes from the preinstalled bootloader on the Discovery board. This is the STLINKv2 protocol. Apparently, you can even use it to connect to a board with gdb (arm-none-eabi-gdb) and have a pretty powerful debugging setup.
If you have a Discovery board, the top half has a USB programmer to do STLINK for you. You can also buy a standalone dongle.
sudo apt-get install automake libusb-1.0-0-dev git clone https://github.com/texane/stlink.git cd stlink ./autogen.sh ./configure make
If you plug the ST-LINK usb port to your computer, you can talk to it with the stlink utilities:
$ lsusb Bus 007 Device 007: ID 0483:3748 SGS Thomson Microelectronics ST-LINK/V2 $ sudo ./st-info --chipid Error: could not open stlink device Error: could not open stlink device 0x0422
You can flash the .bin file you made earlier:
$ sudo ./st-flash write USB_Example.bin 0x8000000 2013-10-01T16:02:16 INFO src/stlink-common.c: Loading device parameters.... 2013-10-01T16:02:16 INFO src/stlink-common.c: Device connected is: F3 device, id 0x10036422 2013-10-01T16:02:16 INFO src/stlink-common.c: SRAM size: 0xa000 bytes (40 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes 2013-10-01T16:02:16 INFO src/stlink-common.c: Attempting to write 19760 (0x4d30) bytes to stm32 address: 134217728 (0x8000000) Flash page at addr: 0x08004800 erased 2013-10-01T16:02:17 INFO src/stlink-common.c: Finished erasing 10 pages of 2048 (0x800) bytes 2013-10-01T16:02:17 INFO src/stlink-common.c: Starting Flash write for VL/F0 core id 2013-10-01T16:02:17 INFO src/stlink-common.c: Successfully loaded flash loader in sram 9/9 pages written 2013-10-01T16:02:18 INFO src/stlink-common.c: Starting verification of write complete 2013-10-01T16:02:18 INFO src/stlink-common.c: Flash written and verified! jolly good!
You can put the demo software it shipped with back on it, as well. One caveat is that st-flash only takes binary (.bin) files, not hex (in plain text, typically .hex), and it won’t complain if you try with the wrong thing. So you have to convert the supplied demo file (at Project/Demonstration/Binary/STM32F3_Discovery_Demo_V1.1.0.hex):
arm-none-eabi-objcopy -O binary -I ihex STM32F3_Discovery_Demo_V1.1.0.hex STM32F3_Discovery_Demo_V1.1.0.bin
And you can flash the resulting .bin file back on the board in the same way as before.
Programming standalone boards (not Discovery)
(This is planning from notes here and elsewhere, I haven’t done this yet).
You can use the Discovery board as a programmer and flash a target board as done above. Just remove the two DISCOVERY jumpers at CN4 and connect the six wire SWD interface appropriately to the target board. See the full Discovery docs for more details (section 4.2.2).
Another option is to flash the board without a programmer, using a simple USART interface. See the “Microcontroller system memory boot mode” application note. Apparently, these chips have a native bootloader that will take serial input on the correct pins directly into flash memory when they are powered on after the correct reset pin sequence (see e.g. the LeafLabs Maple bootloader replacement instructions). Utilities like stm32flash are designed to work in this mode, e.g. using an FTDI cable to your computer. The downside is that you lose the nice debugging support that you get with STLINK.
- Making a minimal example that doesn’t depend on the firmware example package (and uses as little of their library as possible), with the specific MCU version factored out so it can be changed easily.
- Designing, fabricating, and flashing a standalone 32-bit board (LeafLabs Mini as a starting point, looking at Discovery schematics as necessary). See ST’s hardware application note for an overview. Or the full 1705 page reference manual…
- Explore LeafLabs Maple IDE integration with Discovery boards (to make programming easier with this Arduino interface clone). Ideally, there would be a simple boards.txt modification to be able to work with Discovery boards as targets. We could use the IDE for programming and building, and one of the STLINK utilities for flashing (unless we put the Maple bootloader on the Discovery, or hacked up the IDE). See here and here for a discussion.
- Doing anything real with the powerful capabilities of the M4 chips…