1. The Makefile

The Makefile does not contain anything exciting; it's the mostly simplified version of a common cross-compile Makefile; worth to note here, are a couple of details:

• The "magic" rule to convert any .c to its corresponding .o:

%.o: %.c
        $(CC) -c $(CFLAGS) $(INCFLAGS) -o $@ $<

• The CFLAGS settings, used to tell what's the target cpu (Cortex M0) and meant to have no dependencies, even excluding the stdlib:

CFLAGS += -mthumb -Wall -Werror -Os -mcpu=cortex-m0 -ggdb -nodefaultlibs \
        -nostdlib -nostartfiles -ffreestanding

2. The linker script

This is quite an ugly beast for most people (including myself!); the reason is that, when compiling for a PC running an operating system, you won't most ever need know about its existence, but implicitely rely on the one provided by your compiler. The linker script becomes a useful tool when you have all of your RAM and flash under your control, like it happens in bare-metal programming. The linker script is then used to tell your toolchain how to compose your compiled object (.o files) in order to obtain the final binary. The script is heavily based on sections, or segments (for a quick introduction, Wikipedia Data Segment webpage is a good choice).

Linker script syntax is not straightforward, so I won't spend too much time on it, just I will point out what's happening on the first lines, inside the .text section.

.text 0x08000000: {
        *(isrv_sys); /* Interrupt Service Routine Vector - System */
        *(isrv_irq); /* Interrupt Service Routine Vector - Peripherals IRQs */
        . = 0x000000C0;
        *(.text)
}

Basically, the above snippet says this:

• the text code will be placed at address 0x08000000; this is the internal flash base address in STM32F0xx chips;

• the first bytes in the flash will contain the Interrupt Service Routine vector (system and IRQ);

• the proper code will be placed at 0xC0 (192) delta: 192 bytes is the size of the ISR vector(s), so the code is put right after them.

This is the basic setup of any Cortex-M system: you have to prepare your flash with the ISR vectors, then, at boot, the second (32 bits) element of the vector is used as the address of the reset routine, which is the entry point for the execution. A good introduction to how ARM systems boot are the ARM documentation pages themselves.

3. The include/ directory

Here is where I put some generic defines, used inside the .c, and I often copy them from one project to another, as they provide some basic macros and defines; they should be commented enough, so no need to tell more. The most relevant file here is the basic.h file, where macros for registers manipulations (e.g. wr32, rd32, etc) are defined.

Other relevant files are:

• cpu.h: hosts the definitions for some common registers in ARM architecture;

• stm32f411x.h: defines registers for the ST SoC;

• gpio.h: defines some helpers for GPIOs handling.

3. The init.c file

It contains the code automatically called by the chip at startup. As explained above, the cpu expects a list of function pointers to be called in case of interrupts or special events; one of this is the reset; so this is how the isrv_sys array looks like:

static const void *attr_sect("isrv_sys") _isrv_sys[] = {
        /* Cortex-M0 system interrupts */
        STACK_TOP,      /* Stack top */
        isr_reset,      /* Reset */
        isr_nmi,        /* NMI */
        isr_hf, /* Hard Fault */
        0,                      /* Reserved */
        0,                      /* Reserved */
        0,
        [...]

The first element is the RAM stack top address; the second one is the reset routine, here called isr_reset (but you can choose your preferred name), and defined in the same file.

Regarding the isr_reset routine, these are the steps it performs:

• load the data section to RAM: data section is the one containing any preinitialized value in the code;

• set bss section to zero: bss is the static RAM used by the code; it differs with data section in having implicit zero value at boot;

• configure clock and system ticks; system ticks is a variable setted to increment once every 1ms, and can be used for time keeping (see isr_systick function);

• initialize the UART.

4. The main.c file

What I here propose is a very simple main, working as a basic clock on UARt: an infinite loop, waiting for system ticks increments, and writing a dot once every second (1000 system ticks), and a newline once a minute.

5. Conclusions

You can use the code here commented as an exercise to understand how an ARM-based MCU work, with no helps from SDKs nor Operating Systems. With some efforts, the same code can be expanded in order to support medium-complexity applications, with essential-only stuff, direct access to registers small flash, occupancy and full control of what's being done by your code.