Jan 30

Less talk, more code: minimalist bare metal programming from scratch episode 0

I have rebooted my software development activities with the STM32F4-Discovery around a (for me) new concept: minimalist bare metal programming from scratch. The idea is to go through the development of an unlimited number of self-contained applications of increasing complexity, starting from scratch.
More on the concept can be found at bare.
See also my Git repo’s feed on this page.
I could post walk-throughs if there is some interest. Drop me a line in that case.

Nov 14

Back to while_one project on the STM32F4-Discovery

I have left my STM32F4-Discovery in its box for a long time while, among others, working on Nand2Tetris, but I have been missing it. I would now like to rebuild the while_one project from scratch and continue from there, with only the bare necessities:

the two latter simply being unpacked in my home directory, with the purpose of serving as code copy/paste sources, my idea being to include as little generic code as possible in my projects, in order to keep control over it. The tool chain from “GNU Tools” is of course also my tool chain.
I basically run the same procedure as described in Running ARM samples on the STM32F4-Discovery, except that I run GDB in Emacs (M-gdb, command edited to arm-none-eabi-gdb -i=mi). I also change the original ARM Makefile to compile with debugging symbols (see Stm32F4DiscoveryTest).
I can then step through the source code, both the startup assembly code and the C-code in Emacs by using stepi in GDB.
Note: I finally keep the structure provided by the samples in GNU Tools for ARM Embedded Processors because it has a simple Makefile hierarchy, and seems to limit boilerplate code to a minimum. My intention is to build further from minimum.c, which basically is a “while one” program (it is actually a “for (;;);” program).

Jun 21

Discovering the STM32F4-Discovery

The official page is at STM32F4DISCOVERY. The board features:

  • An STM32F407VGT6 microcontroller featuring 32-bit ARM Cortex-M4F core, 1 MB Flash, 192 KB RAM, a frequency of up to 168 MHz, in an LQFP100 package.

That MCU has two boot pins that control where it boots from. For some strange reason, I was not able to find a complete specification of those pins in ST’s documentation. However, it looks like the information located at stm32-arm-cortex-bootloader is correct:

BOOT0 BOOT1 Boot Mode
0 X Boot from user flash
1 0 Boot from System Memory
1 1 Boot from embedded RAM

According to the STM32F407VG datasheet, system memory is apparently some kind of PROM, where a serial boot loader is located, that can be used to reprogram the flash. My intention is to rather boot from flash, and use the openocd over the ST-LINK/V2 interface, probably integrated in Eclipse at some point, to reprogram the flash.
According to the STM32F407 user manual, the standard BOOT0/BOOT1 configuration is 0/1, which is fine for me (booting from flash).

Jun 21

Starting talking to STM32F4-Discovery from Linux

Used host:

First, I add the udev rule corresponding to the ST-LINK/V2 interface in the newly created file /etc/udev/rules.d/99-stlink.rules (thanks PulkoMandy):

Then, I trigger the new udev rule:

Then I install openocd 0.8.0-2 from the Community repository, resulting in:

Then, I connect the board’s Mini-USB connector to my computer. It will both give power to the board, and make the ST-LINK/V2 interface accessible. The ST-LINK/V2 interface appears as a USB device:

Then, I say hello to my little board:

What more would a nerd require to be happy? :-)