DEV Community: Can Gulmez

An introduction to ARM Cortex-M3/4

Can Gulmez — Fri, 17 Jul 2026 16:00:39 +0000

Another tutorial series on writing a RTOS kernel...

I'm starting a new series about writing a RTOS kernel for ARM Cortex-M3/4 processors which are the base choices for commonly used STM32, NXP microcontrollers. I plan giving the all theoretical and practical details so that you guys will have the skills that most engineer don't have.

Firstly, let me give the my notes on the processors itself.

Architecture

The Cortex-M3 and Cortex-M4 processors are ARMv7-M architecture.

Programmer's Model

Both processors have two operation status and two modes:

Handler mode: When executing an exception handler such as ISR. When in handler mode, the processor always has privileged access level.
Thread mode: When executing normal application code, the processor can be either in privileged access level or unprivileged level. This is controlled by a special register called CONTROL.

Software can switch the processor in privileged thread mode to unprivileged thread mode. However, it cannot switch itself back from unprivileged to privileged.

Registers

Registers R0-R12 are general purpose registers. The first eight (R0-R7) are also called low registers. Due to the limited available space in the instruction set, many 16-bit instructions can only access the low registers. The higher registers (R8-R12) can be used with 32-bit instructions, and a few with 16-bit instruction. The initial values of R0-R12 are undefined.

R13, Stack Pointer (SP) is used for accessing the stack memory via PUSH and POP operations. Physically there are two different: Main Stack Pointer (MSP) and Process Stack Pointer (PSP).

The selection of SP is determined by a special register called CONTROL.

For most cases, it is not necessary to use the PSP if the application doesn't require an embedded OS. Many simple applications can rely on the MSP completely. The PSP is normally used when an embedded OS is involved, where the stack for the OS kernel and application tasks are separated. The initial value of PSP is undefined, and the initial of MSP is taken from the first word of the memory during the reset sequence.

R14, Link Register (LR) is used for holding the return address when calling a function or subroutine. During exception handling, the LR is also updated automatically to a special EXC_RETURN value, which is then used for triggering the exception return at the end of the exception handler.

R15, Program Counter (PC) returns the current instruction address plus 4 (this is due to the pipeline nature of the design).

Behavior of the Application Program Status Register

The Program Status Register is composed of three status registers:

Application PSR (APSR)
Execution PSR (EPSR)
Interrupt PSR (IPSR)

These three registers can be accessed as one combined register, referred to as xPSR.

The PRIMASK, FAULTMASK, and BASEPRI registers are all used for exception or interrupt masking. Each exception has a priority level where a smaller number is a higher priority. These special registers are used to mask exceptions based on priority levels.

The PRIMASK register is a 1-bit wide interrupt mask register. When set, it blocks all exceptions apart from the NMI and HardFault exception. The most common usage is to disable all interrupts for a time critical process. The FAULTMASK register is very similar to PRIMASK, but it also blocks the HardFault exception. Unlike PRIMASK, FAULTMASK is cleared automatically at exception return. The BASEPRI makes exceptions or interrupts based on priority level. When BASEPRI is set to 0, it is disabled. When it is set to a non-zero value, it blocks exceptions (including interrupts) that have the same or lower priority level., while allowing exceptions with a higher priority level to be accepted by the processor.

The CONTROL register defines:

The selection of stack pointer (MSP or PSP)
Access level in thread mode (privileged/unprivileged)

In addition, for Cortex-M4 processor with a floating point unit, one bit of the CONTROL register indicates if the current context uses the floating point unit or not.

The Cortex-M4 processor has an optional floating-point unit. This provides additional registers for floating-point data processing, as well as a Floating Point Status and Control Register (FPSCR). S0-S32 ("S" means single precision) and D0-D15 ("D" means double precision) can be accessed using floating-point instructions.

Memory System

The Cortex-M3/4 processors have the following memory system features:

4GB linear address space with 32-bit addressing.
Architecturally defined memory map - the 4GB memory space is divided into a number of regions for various predefined and peripheral uses.
Support for little- and big-endian memory systems.
Bit band accesses - this allows atomic access to individual bits in SRAM or peripheral address space.
Memory Protection Unit (MPU) - The MPU is a programmable unit which defines access permissions for various memory regions.
Unaligned transfer support

The MPU can be used to protect memory regions by means of defining access permissions in privileged and unprivileged access states.

Exception and Interrupt

Exceptions are events that cause changes to program flow. When one happens, the processor suspends the current execution task and executes a part of the program called the exception handler. After the execution of the exception handler is completed, the processor then resumes normal program execution. Interrupts are one type of exception and generally are generated from peripheral or external inputs, and in some cases they can be triggered by software. The exception handlers for interrupts are also referred to as Interrupt Service Routines (ISRes).

Each exception source has an exception number. Exception numbers 1 to 15 are classified as system exceptions, and exceptions 16 and above are for interrupts.

The NVIC (Nested Vectored Interrupt Controller) handles the exceptions and interrupt configurations, prioritization, and interrupt masking. The NVIC has the following features:

Flexible exception and interrupt management
Nested exception/interrupt support
Vectored exception/interrupt entry
Interrupt masking

When an exception event tasks place and is accepted by the processor code, the corresponding exception handler is executed. To determine the starting address of the exception handler, a vector table mechanism is used. The vector table is an array of word data inside the system memory, each representing the starting address of one exception type.

Several types of exceptions are fault handling exceptions. By default the BusFault, UsageFault, and MemManageFault are disabled and all fault events trigger the HardFault exceptions. However, the configurations are programmable and you can enable the three programmable fault exceptions individually to handle different types of faults. The HardFault exception is always enabled.

System Control Block (SCB)

The SCB contains various registers for:

Controlling processor configurations (e.g., low-power mode)
Providing fault status information (fault status registers)
Vector Table Relocation (VTOR)

Debug

There are two types of interfaces provided in the Cortex-M processors: debug and trace. The debug interface allows a debug adaptor to connect to a Cortex-M microcontroller to control the debug features and access the memory space on the chip. The Cortex-M processor supports both JTAG and SWD.

The trace interface is used to collect information from the processor during run-time such as data, event, profiling information, or even complete details of program execution.

Reset and Reset Sequence

In typical Cortex-M microcontrollers, there can be three types of reset:

Power on reset - reset everything in the microcontroller. This includes the processor and its debug support component and peripherals.
System reset - reset just the processor and peripherals, but not the debug support component of the processor.
Processor reset - reset the processor only.

After reset and before the processor starts executing the program, the Cortex-M processors read the first two words from the memory. The beginning of the memory space contains the vector table, and the first two words in the vector table are the initial value for MSP.

Instruction Set

The SuperVisor Call (SVC) instruction is used to generate the SVC exception. Typically, SVC is used with an embedded RTOS, where an application task running in an unprivileged execution state can request services from the OS, which runs in the privileged execution state. The SVC exception mechanism provides the transition from unprivileged to privileged.

The switching of PRIMASK or FAULTMASK to disable and enable an interrupt is commonly used to ensure timing critical code can finish quickly without getting interrupted.

There are two main instructions for entering sleep modes: Wait for Interrupt (WFI) and Wait for Event (WFE).

Memory barrier instructions:

DMB (Data Memory Barrier); ensures that all memory accesses are completed before new memory access is committed.
DSB (Data Synchronization Barrier); ensures that all memory accesses are completed before next instruction is executed.
ISB (Instruction Synchronization Barrier); flushes the pipeline and ensures that all previous instructions are completed before executing new instructions.

Exception and Interrupts

When the Cortex-M processor accepts an exception request, the processor needs to determine the starting address of the exception handler. This information is stored in the vector table in the memory. By default, the vector table starts at memory address 0, and the vector address is arranged according to the exception number times. The vector table is normally defined in the startup codes provided by vendors.

The vector table used in startup code also contains the initial value of the main stack pointer (MSP).

There are various status attributes applicable to each interrupt:

Each interrupt can be either disabled or enabled
Each interrupt can be either pending or not pending
Each interrupt can be either in active or inactive state

The processor accepts an exception if the following
conditions are met:

The processor is running
The exception is enabled
The exception has higher priority than the current priority level
The exception is not blocked by an exception masking register

An exception entrance sequence contains several operations:

Stacking of a number of registers.
Fetching the exception vector.
Fetching the instructions in parallel to the stacking operation to reduce latency.
Fetching the instructions for the exception handler to be executed.

Exception Handling in Detail

You can program your exception handlers or ISR as normal C routines/functions.

R0-R3, R12, LR, and PSR are called "caller saved registers". The program code that calls a subroutine needs to save these register contents into memory before the function call if these values will still be needed after the function call. Register values that are not required after the function call don't have to be saved.

R4-R11 are called "callee-saved registers". The subroutine or function being called needs to make sure the contents of these registers are unaltered at the end of the function. The values of these registers could change in the middle of the function execution, but need to be restored to their original values before function exit.

In order to allow a C function to be used as an exception handler, the exception mechanism needs to save R0-R3, R12, LR, and PSR at exception entrance automatically, and restore them at exception exit under the control of the processor's hardware.

So in total eight registers need to be saved during the
exception handling sequence. For the Cortex-M4 processor with floating-point unit, the exception mechanism also needs to save S0-S15 and FPSCR if the floating-point unit is used. This is indicated by a bit in the CONTROL register called FPCA.

As the processor enters the execution handler or Interrupt Service Routine (ISR), the value of the LR is updated to code called EXC_RETURN. The value of this code is used to trigger the exception return mechanism when it is loaded into the PC.

When an exception occurs and is accepted by the processor, the stacking sequence starts to push the registers into the stack, forming the stack frame.

The term 'interrupt latency' refers to the delay from the start of the interrupt request to the start of the interrupt handler execution.

Low Power and System Control Features

Today we see many low power Cortex-M microcontrollers with very sophisticated system features that enable longer battery life. For example:

Various run modes and sleep modes are available
Ultra low power Real-Time Clock (RTC), watchdog and Brown-Out Detector (BOD)
Smart peripherals that can operate while the processor remains in sleep mode
Flexible clock system control features to allow clock signals for inactive parts of the design to be turned off

The processor support two sleep modes: Sleep and Deep Sleep. The Cortex-M processor provides a register called the System Control Register (SCR) to allow you to select between the Sleep mode and Deep Sleep mode.

The processor provides two instructions for entering sleep modes: WFI and WFE.

WFE can be woken up by any events. This event register can be set by:

Exception entrance and exit
When SEV-On-Pend feature is enabled
An External Event Signal (RXEV) from on-ship hardware
Execution of the SEV (Send Event) instruction
Debug event

The Sleep-on-Exit feature is very useful for interrupt driven applications where all operations are carried out inside the interrupt handler. When enabled, the Cortex-M processor automatically enters sleep mode when exiting from an exception handler and returning to thread mode.

The Cortex-M processors have a small integrated timer called the SysTick timer. It is integrated as a part of the NVIC and can generate the SysTick exception. The SysTick timer is a simple decrement 24-bit timer, and can run on processor clock frequency or from a reference clock frequency.

OS Support Features

A number of features are implemented in the architecture to make OS implementation easier and more efficient. For example:

Shadowed stack pointer: Two stack pointers are available. The MSP is used for the OS kernel and interrupt handlers. The PSP is used by application tasks.
SysTick timer: A simple timer included inside the processor. This enables an embedded OS to be used on the wide range of Cortex-M microcontrollers available.
SVC and PendSV exceptions: These two exception types are essential for the operations of embedded OSs such as the implementation of context switching.
Unprivileged execution level: This allows a basic security model that restricts the access rights of some application tasks.
Exclusive accesses: The exclusive load and store instructions are useful for semaphore and mutual exclusive operations in the OS.

MSP is the default stack pointer. It is used in the thread mode when the CONTROL bit1 is 0, and it is always used in handler mode.

PSP is used in thread mode when the CONTROL bit 1 is set to 1.

Stack operations like PUSH and POP instructions, and most instructions that use SP use the currently selected stack pointer. You can also access the MSP and PSP directly using MRS and MSR instructions. In simple applications without an embedded OS or RTOS, you can just use the MSP for all operations and ignore the PSP.

In system with an embedded OS or RTOS, the exception handlers use the MSP, while application tasks use the PSP. Each application task has its own stack space, and the context-switching code in the OS updates the PSP each time the context is switched.

Typically, to use the process stack, put OS in handler mode, and program PSP directly, then use an exception return sequence to "jump" into the application task.

For example, when an OS first starts in thread mode, it can use the SVC exception to enter the handler mode. Then it can create a stack frame in the process stack, and trigger an exception return that uses the PSP. When the stack frame is loaded, the application is started.

In OS designs, we need to switch between different tasks. This is typically called context-switching. Context-switching is usually carried out in the PendSV exception handler, which can triggered by the periodic SysTick exception. Inside the context-switching operation, we need to:

Save the current status of the registers in the current task
Save the current PSP value
Set the PSP to the last SP value for the next task
Restore the last values for the next tasks
Use exception return to switch to the task

The SVC exception is generated using the SVC instruction. An immediate value is required for this instruction, which works as a parameter-passing method. The SVC exception handler can then extract the parameter and determine what action it needs to perform. For example:

SVC #0x3 ; Call SVC function 3

The PendSV exception is triggered by setting its pending status by writing to the Interrupt Control and State Register (ICSR). Unlike the SVC exception, it is not precise. So its pending status can be set inside a higher priority exception handler and executed when the higher-priority handler finishes. Using this case, we can schedule the PendSV exception handler to be executed after all other interrupt processing tasks are done, by making sure that the PendSV has the lowest exception priority level. This is very useful for a context switching operation, which is key operation in various OS designs.

Below shows an example sequence of context-switching using PendSV with the following event sequence:

Task A calls SVC for task switching.
The OS receives the request, prepares for context switching, and pends the PendSV exception.
When the CPU exits SVC, it enters PendSV immediately and does the context switch.
When PendSV finishes and returns to thread level, it executes Task B.
An interrupt occurs and interrupt handler is entered.
While running the interrupt handler routine, a SysTick exception takes place.
The OS carries out the essential operation, then pends the PendSV exception and gets ready for the context switch.
When the SysTick exception exits, it returns to the interrupt service routine.
When the interrupt service routine completes, the PendSV starts and does the actual context-switch operations.
When PendSV is complete, the program returns to thread level; this time it returns to task A and continues the processing.

In a multi-tasking system, it is common that a number of tasks need to share a limited number of resources. This feature is usually called a semaphore. For the case when only one resource is available, it is also called mutual exclusive, which is one type of semaphore.

The processor supports a feature called exclusive access. The semaphore variable are read and written using exclusive load and exclusive store.

Fault Exceptions and Fault Handling

By default, all the faults trigger the HardFault exception. Cortex-M3/4 processors have three additional configurable fault exception handlers:

MemManageFault
BasFault
UsageFault

These exceptions are triggered if they are enabled, and if their priority is higher than the current exception priority level. These exceptions are called 'configurable fault' exceptions, and have programmable exception priority levels.

The fault handlers can be used in a number of ways:

Shut down the system safely
Inform users or other systems that it encountered a problem
Carry out self-reset
In the case of multi-tasking systems, the offending tasks could be terminated and restarted
Other remedial actions can be carried out o try to fix the problem if possible

The help detect what type of error was encountered in the fault handler, the Cortex-M3/4 processors also have a number of Fault Status Registers (FSRs). The status bits inside these FSRs indicate the kind of fault detected.

Causes of faults:

Memory management faults
Bus faults
Usage faults
Hard Faults

Floating-Point Operations

The Floating Point Unit (FPU) in the Cortex-M4 processor is optional and supports single precision floating point
calculations. The FPU in the Cortex-M4 processor is based on an extension of the ARMv7-M architecture called FPv4-SP (Floating Point version 4 - Single Precision). This is a subset of the VFPv4-D16 extension for ARMv-7A and ARMv7-R architecture.

The FPU adds a number of registers to the processor system:

CPACR (Co-processor Access Control Register) in SCB (System Control Block)
Floating point register bank
Floating point Status and Control Register (FPSCR)

Introduction to the Debug and Trace Features

Two types of trace interface operation modes are supported: either a single-pin model called Serial Wire Viewer (SWV) (using a signal called Serial Wire Output (SWO)), or multi-pin Trace Port interface.

The debug and trace features of the Cortex-M processors are designed based on the CoreSight Debug architecture.

Many Cortex-M microcontrollers support both JTAG and SWD protocols.

Another part of the CoreSight architecture concerns trace data handling. In the Cortex-M3/4 processors, there can be three types of trace source:

Embedded Trace Macrocell (ETM)
Data Watchpoint and Trace (DWT)
Instrumentation Trace Macrocell (ITM)

I think that I've noted the all required details to start writing the RTOS kernel. In next post, I will start writing it.

Resources:

The Definitive Guide to ARM Cortex-M3 and ARM Cortex-M4 Processors, Third Edition, Joseph Yiu, Newnes, 2014

Embedded Linux Development - Part 6

Can Gulmez — Tue, 21 Apr 2026 09:03:18 +0000

In this tutorial, I will continue to discuss embedded Linux development with ssh server activation. Previously, I've entered into BeagleBone Black over J1 serial header with a USB-UART converter. In here, I will show that how to enter into it with ssh command.

Firstly, there are two important points that you have to do. I've already did these in previous tutorials. Firstly, I compiled the kernel with USB Gadget module and secondly, I installed openssh-server package into the rootfs. USB gadget module enables the USB connection as the virtual ethernet adapter.

Let's do required settings for both side. Use the J1 serial header again to enter into the BeagleBone Black.

Type the "root" and the your password (set in previous tutorial). Also creating a normal user is good practice.

root@can:/# useradd -m -s /bin/bash can
root@can:/# passwd can
root@can:/# usermod -aG sudo can

I've created a user named "can" and set the its password. After that go to the your home directory and create a bash script. I named it as setup-usb-gadget.sh.

root@can:/home/can# ls
setup-usb-gadget.sh

Open and copy this into that:

#!/bin/bash

INTERFACE="usb0"
IP_ADDR="198.168.7.2/24"

# Load the g_ether kernel module that creates the ethernet virtual link.
modprobe g_ether

# Configure the link interface.
ip addr flush dev "$INTERFACE"
ip link set "$INTERFACE" up
ip addr add "$IP_ADDR" dev "$INTERFACE"

# Ensure that SSH is running.
systemctl start ssh

In here, I loaded the g_ether module into the kernel. It's the name of USB gadget module. It will create usb0 interface. After that I set it as "up" and its IP address as "198.168.7.2". You can give any IP address, doesn't matter. But generally, "198.168.7.2" is used. Lastly make sure that ssh server is enabled.

Set the executable permission:

root@can:/home/can# chmod +x ./setup-usb-gadget.sh

And then run it.

root@can:/home/can# ./setup-usb-gadget.sh 
[  644.487501] g_ether gadget.0: HOST MAC f6:b0:84:e3:dc:c2
[  644.493125] g_ether gadget.0: MAC e2:87:7a:43:97:1d
[  644.498588] g_ether gadget.0: Ethernet Gadget, version: Memorial Day 2008
[  644.505565] g_ether gadget.0: g_ether ready
[  644.522283] PM: Cannot get wkup_m3_ipc handle

Lastly, list the available interface on BeagleBone Black:

root@can:/home/can# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 64:8c:bb:f2:25:78 brd ff:ff:ff:ff:ff:ff
4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e2:87:7a:43:97:1d brd ff:ff:ff:ff:ff:ff
    inet 198.168.7.2/24 brd 198.168.7.255 scope global usb0
       valid_lft forever preferred_lft forever
    inet6 fe80::e087:7aff:fe43:971d/64 scope link 
       valid_lft forever preferred_lft forever

You see the "usb0" interface. That's enough for BeagleBone Black. Let's continue with host side. Open a new terminal and list the available interfaces on host:

can@can:~$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether e8:6a:64:19:45:15 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b0:fc:36:c1:cf:eb brd ff:ff:ff:ff:ff:ff
    inet 10.152.197.93/24 brd 10.152.197.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 3521sec preferred_lft 3521sec
    inet6 fe80::18fc:91fe:ea80:8fad/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether fa:47:d4:7a:67:3e brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
13: enxf6b084e3dcc2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether f6:b0:84:e3:dc:c2 brd ff:ff:ff:ff:ff:ff

BeagleBone Black seems as "enxf6b084e3dcc2" for now. You probably see the different name. It doesn't matter. As wee did in BeagleBone Black, let's do the same things at host side:

can@can:~$ ip addr flush dev enxf6b084e3dcc2
can@can:~$ sudo ip link set enxf6b084e3dcc2 up
can@can:~$ sudo ip addr add 198.168.7.1/24 dev enxf6b084e3dcc2

I assigned the IP address "198.168.7.1" to host (I did "198.168.7.2" for BeagleBone Black).

Lastly, ping BeagleBone Black interface:

can@can:~$ ping 198.168.7.2
PING 198.168.7.2 (198.168.7.2) 56(84) bytes of data.
64 bytes from 198.168.7.2: icmp_seq=1 ttl=64 time=0.904 ms
64 bytes from 198.168.7.2: icmp_seq=2 ttl=64 time=0.351 ms
64 bytes from 198.168.7.2: icmp_seq=3 ttl=64 time=0.449 ms
64 bytes from 198.168.7.2: icmp_seq=4 ttl=64 time=0.478 ms
64 bytes from 198.168.7.2: icmp_seq=5 ttl=64 time=0.585 ms
64 bytes from 198.168.7.2: icmp_seq=6 ttl=64 time=0.477 ms
^C
--- 198.168.7.2 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5114ms
rtt min/avg/max/mdev = 0.351/0.540/0.904/0.176 ms

That's okey 🥳🥳🥳🥳. You can connect to BeagleBone Black with ssh command for now:

can@can:~$ ssh can@198.168.7.2
can@198.168.7.2's password: 
Linux can 6.14.0-ge8b471285262 #1 SMP Mon Apr 13 12:31:38 +03 2026 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Jan  1 00:43:51 2000 from 198.168.7.1
can@can:~$ 
can@can:~$ ls
setup-usb-gadget.sh
can@can:~$ cd ..
can@can:/home$ cd ..
can@can:/$ ls
bin  boot  dev  etc  home  lib  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

You don't need anymore J1 serial header. You can use it within the ssh terminal for now. Also you can set the setup-usb-gadget.sh as startup script so that it runs automatically after the boot.

In next tutorial, I will inspect the uEnv.txt file and u-boot console. You can make many interesting tricks in there.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part 5

Can Gulmez — Tue, 14 Apr 2026 13:18:52 +0000

Until here, I've talked about the embedded Linux development in four stage: toolchain, bootloader, Linux kernel, rootfs. In this tutorial, I will create a SD card image including these and then run it in BeagleBone Black.

Firstly, let's remember that what I've produced from these stages:

MLO (second-stage bootloader)
u-boot.img (main bootloader)
uEnv.txt (commands for the bootloader)
zImage (compressed the kernel image)
am335x-boneblack.dtb (device tree for the kernel)
Debian rootfs (including the kernel modules)

How can I create a SD card image including all of these?

Firstly, I need to create two partitions, one for booting and second for rootfs. So plugin the SD card into the PC (I'm on Ubuntu) and create the partitions:

$ sudo parted -s /dev/sdX mklabel msdos # parition table and partitions

$ sudo parted -s /dev/sdX mkpart primary fat32 1MiB 65MiB # boot partition (FAT32, 64MB)
$ sudo parted -s /dev/sdX set 1 boot on # make it first parititon

$ sudo parted -s /dev/sdX mkpart primary ext4 65MiB 100% # rootfs parititon (ext4, rest of SD card)

$ sudo mkfs.vfat -F 32 -n boot /dev/sdX1 # format the boot partition
$ sudo mkfs.ext4 -L rootfs /dev/sdX2 # format the rootfs partition

In here, I created the "boot" partition which was formatted with FAT32 and "rootfs" partition with ext4. Why did I create two distinct partitions? The first reason is that the kernel loads and runs the rootfs. So the bootloader cannot reside in the rootfs because of the bootloader runs before the kernel. Second reason is that the bootloader works with FAT32 better (even if the FAT32 size is much bigger).

After that, copy the MLO, u-boot.img, uEnv.txt, zImage, am335x-boneblack.dtb into the "boot" partition. Also copy the your rootfs content into the "rootfs" partition.

That's it. The SD card is ready to run the BeagleBone Black. So plugin the SD card and then power up the board. Well how to enter into the Debian rootfs? There is a J1 header besides the P9. It's the serial port. Pin 1 is GND, 4 is RX and 5 is TX. Use FT232R converter to connect these pins to PC.

To see the outputs, open a terminal and the type:

$ screen /dev/ttyUSBX 115200 # or /dev/ttyACMX

Reboot the BeagleBone Black and then you will see the u-boot and the kernel messages. Lastly, you will see the login session:

Type the "root" and the password (you set it in previous tutorial). That's it. You are in the BeagleBone Black terminal.

You can do whatever you want after that 🥳🥳🥳.

In the next tutorial, I will show that how to use ssh command so that you can easily make connection over USB cable, not needing to J1 header.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part 4

Can Gulmez — Mon, 13 Apr 2026 17:15:36 +0000

In this tutorial, I will go with the fourth stage of embedded Linux development which is the rootfs.

Every Linux-based system have a filesystem. If you are on GNU/Linux, you already probably know it and how it structured.

Apart from that embedded Linux needs a few special applications to start up the system. The init is the first program that runs on user-space so that its process ID always is 1. This init program is responsible for start the other user-space applications and services like shell. It generally resides at /sbin/init, /etc/init, /bin/init or so on. The kernel try to find it and then run.

The organization of a Linux rootfs in terms of directories is well-defined by the Filesystem Hierarchy Standard. The general hierarchy:

/bin: Basic programs
/boot: Kernel images, configurations and booting tools
/dev: Device files
/etc: System-wide configuration
/home: Directory for the users home utilities
/lib: Basic libraries
/media: Mount points for removable media
/mnt: Mount point for a temporarily mounted filesystem
/proc: Mount point for the proc virtual filesystem
/root: How directory of the root user
/run: Run-time variable data
/sbin: Basic system programs
/sys: Mount point of the sysfs virtual filesystem
/tmp: Temporary files
/usr: User-specific utilities
/var: Variable data files, for system services

So in summary, I need to create a Linux rootfs and then put the required applications in there. I also want to build a development environment. For example, I want to run python 3 scripts, compiling C/C++ programs, or so on. But how?

There are three options here:

Building everything from scratch
A minimal BusyBox rootfs
A Debian rootfs with debootstap

Which option is for me?

Building everything from scratch means that creating the directories and then fetch the every program, package, library by hand. It means the hell of package dependency! It's not for me.

A minimal rootfs can be created with BusyBox easily. It can create the classic Linux directories and put the core utilities in there like cp, mkdir, ls or so on. If you're making embedded Linux system first time and just focusing on a "running" system, BusyBox is for you. But I need more. I wanna create a development environment!

The right tool is debootstrap program. It creates a base Debian rootfs including the utilities that we're using everyday like apt, systemctl, vi, or so on. This Debian rootfs is around ~200MB, while BusyBox rootfs is ~1MB.

By the way, if you want to go with BusyBox rootfs (while I'm not), below is the required commands:

$ git clone https://git.busybox.net/busybox
$ cd busybox
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc)
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig # optional
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- CONFIG_PREFIX=path/to/linux/rootfs install

Let's focus on debootstrap. Firstly download it.

$ sudo apt install qemu-user-static debootstrap

In here, I also installed qemu-user-static which lets me to run the ARM binaries onto x86_64.

Let's create the base Debian rootfs:

$ sudo debootstrap --arch=armhf --foreign bookworm path/to/linux/rootfs http://deb.debian.org/debian
$ sudo chroot path/to/linux/rootfs /debootstrap/debootstrap --second-stage

In here, bookworm is the nickname of Debian 12 which is the last stable version.

These two commands download the rootfs and then unpack it. So it takes some time (~30 minutes in my case). Don't forget, these just fetch the required and important packages from the Debian database, not fully OS.

The rootfs is ready to be used. But there are some tricks that you always must do:

$ sudo cp /usr/bin/qemu-arm-static <path/to/linux/rootfs>/usr/bin/

I also want to install the additional packages and make some settings. For example, you always must set the password. That means I need to run this rootfs on my Ubuntu host:

$ sudo chroot path/to/linux/rootfs

First thing you must is to update the password:

root@can:/# passwd
New password: 
Retype new password: 
passwd: password updated successfully

Install the additional packages if you want:

root@can:/# apt install gcc python3 vim openssh-server # and what you need

In here, make sure that you install the openssh-server. It's required for ssh command.

Lastly, I need to install the kernel modules in this rootfs. Go back to the kernel source and run:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=path/to/linux/rootfs modules_install

That's it. I created the proper Debian rootfs that I can make software development. In the next tutorial, I will use the all artifacts coming from u-boot, the kernel and the rootfs to make SD card image.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part 3

Can Gulmez — Mon, 13 Apr 2026 14:02:29 +0000

In this tutorial, I'll go with the third stage of embedded Linux development. That's the Linux kernel.

It's the responsible for:

Manage all the hardware resources: CPU, memory, I/O.
Provide a set of portable, architecture and hardware independent APIs to allow user space applications and libraries to use the hardware resources.
Handle concurrent accesses and usage of hardware resources set of system calls.

The kernel provides about 400 system calls that provide the services like opening the disk file, forking the new process, managing the memory or so on. These system calls are defined in /usr/include/x86_64-linux-gnu/asm/unistd.h like:

#define __NR_read 0
#define __NR_write 1
#define __NR_open 2
#define __NR_close 3
#define __NR_stat 4
#define __NR_fstat 5
#define __NR_lstat 6
#define __NR_poll 7
#define __NR_lseek 8
#define __NR_mmap 9
#define __NR_mprotect 10
#define __NR_munmap 11
#define __NR_brk 12

(...)

In user-space applications, we generally don't use these system calls directly. These system calls are wrapped by the standard POSIX C library. If you're a programmer, you already know it.

Let's start with downloading Linux kernel:

$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

I have the 6.14 kernel (slightly older, but doesn't matter). As you see that the kernel contains thousands of device drivers, filesystem drivers, network protocols and other configurable items.

As I did previously at u-boot stage, the first thing is to configure the kernel according to BeagleBone Black over configuration files (ends with _defconfig).

Which configuration file should be used for BeagleBone Black? It's omap2plus_defconfig under linux/arch/arm/configs (OMAP is the processor family including the AM335x Sitara processor by TI).

So let's configure the kernel:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- omap2plus_defconfig

It will create the .config and write the associated configs in it.

As I said, this configuration file includes the generic AM335x Sitara processor configs. To customize and tailor the kernel further:

$ make menuconfig # or xconfig (for Qt-based)

It will open the terminal-based GUI window to select/unselect the configurable items like:

If you're unfamiliar or newer, I DON'T recommend it. But I need to make an important configuration in here about the USB gadget support. As I will explain in the next tutorail, I wanna use the ssh command to make connection with BeagleBone Black. If you don't make it, you're totally free.

Navigate to Device Drivers --> USB Support --> USB Gadget Support --> USB Gadget precomposed configurations --> Ethernet Gadget (with CDC Ethernet support), type "M" and then exit by saving. It will create the virtual USB link so that I can use the ssh command to connect to BeagleBone Black. I will explain it in the last tutorial in detail.

By the way, you will see the "*" and "M" marks as you navigate the configs. "*" means that the configs will be embedded into the kernel image, while "M" means that the configs is built as modules. These are plugins that can be loaded/unloaded dynamically at runtime to the kernel.

After configured the kernel, for now, you're ready to build the required outputs.

Which outputs exactly should be built from the kernel source? Three things:

zImage
am335x-boneblack.dtb
kernel modules

zImage is the compressed the Linux kernel image. am335x-boneblack.dtb is the device tree blob that describes the hardware connected to the kernel. The kernel modules also are being compiled externally, not embedded into the kernel image.

In here, I have to explain the device tree concept. It's the description of the hardware that the kernel manages at runtime. As you expect, the kernel must know the hardware that it will manage. It's written generally by the processor vendor or development board engineers. The device tree corresponding to BeagleBone Black is the am335x-boneblack.dts under linux/arch/arm/boot/dts/ti/omap.

To produces these outputs:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc) zImage dtbs modules

It will take for a while (~1 hours in my case). After that you will see the zImage under linux/arch/arm/boot and am335x-boneblack.dtb under linux/arch/arm/boot/dts/ti/omap.

The kernel modules are compiled ending with .ko suffix. After the rootfs is being created, I will install these kernel modules in it:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=path/to/linux/rootfs modules_install

But DON'T do it for now. I need to create a rootfs firstly and then install the kernel modules in there. I will show it in the next tutorial.

That's it. I've produced the three essential components from the kernel source: zImage, am335x-boneblack.dtb, and kernel modules. In the next tutorial, I will interest with the rootfs.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part 2

Can Gulmez — Sun, 12 Apr 2026 19:10:26 +0000

In this post, I will continue the embedded Linux development series with second stage which is the bootloader.

Firstly, a bit theoretical background.

The bootloader is a piece of code responsible for:

Basic hardware initialization
Loading of an application binary, usually an operating system kernel, from flash storage, from the network, or from another type of non-volatile storage
Possible decompression of the application binary
Execution of the application

Besides these basic functions, most bootloaders provide a shell or menu:

Menu to select the operating system to load
Shell with commands to load data from storage or network, inspect memory, perform hardware testing/diagnostics

Boot process highly is depended to processor. Let's focus on AM335x Sitara (ARM) booting sequence.

Most embedded processors include a ROM code that implements the initial step of the boot process. It's called the first-stage loader. This ROM code is written by the processor vendor directly built into the processor. That means, it cannot be changed or updated by the others. It initializes the CPU and internal SRAM. It also searches the MLO from NAND/NOR flash, from USB, from SD card, from eMMC, etc.

MLO is a file that you need to produce from the bootloader source code. It's called also second-program loader (SPL). Its mission is to initialize the DDR RAM and run the main bootloader.

The main bootloader initializes the hardware and then loads the Linux kernel and then jump to it. I will use the U-Boot. It's the mostly used bootloader in embedded world.

In summary, the booting process: ROM code --> MLO (SPL) --> U-Boot --> Linux kernel.

So after compiled the u-boot, I expect these:

MLO
u-boot.img

Let's produce these.

Firstly, download the u-boot:

$ git clone https://source.denx.de/u-boot/u-boot.git

If you look at the source code, you will see that the u-boot supports a lot of processors and boards. So first thing you should do is to configure the u-boot over configuration files (ends with *_defconfig) under u-boot/configs.

But which exactly configuration file corresponds to BeagleBone Black? The answer is am335x_evm_defconfig. It's generic AM335x Sitara processor configuration file.

To use this configuration file:

$ make am335x_evm_defconfig

It will create the .config file and write the configs in it. The important point is that you never edit this file by hand.

To customize and tailor this configs further:

$ make menuconfig     # or xconfig (for Qt-based)

It will open the terminal-based GUI to select/unselect the configs. If you are unfamiliar or newer, you should NOT do it. Because it will show the tons of different configs and it can seem messy. The previous command already made the generic required configs.

After setting up the configs, let's build the outputs.

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-

It will take for a while. Because it will compile the tons of source file and then link them together. The output will be like:

(...)

  AR      spl/fs/fat/built-in.o
  CC      spl/fs/fs_internal.o
  AR      spl/fs/built-in.o
  CC      spl/net/arp.o
  CC      spl/net/bootp.o
  CC      spl/net/eth-uclass.o
  CC      spl/net/eth_common.o
  CC      spl/net/net.o
  CC      spl/net/ping.o
  CC      spl/net/tftp.o
  AR      spl/net/built-in.o
  LDS     spl/u-boot-spl.lds
  LD      spl/u-boot-spl
  OBJCOPY spl/u-boot-spl-nodtb.bin
  COPY    spl/u-boot-spl.bin
  MKIMAGE MLO
  MKIMAGE MLO.byteswap
  SYM     spl/u-boot-spl.sym
  MKIMAGE u-boot-dtb.img
  OFCHK   .config

After that you can see the u-boot/MLO, u-boot/u-boot.img and a lots of other files.

As I said before, I need the MLO and u-boot.img and will use these in further. For now, just keeps these in mind.

There is also one more important file that I need. It's uEnv.txt and used by the u-boot when loading the Linux kernel. It consists of the key-value pairs that tell some command to u-boot. So create a new file named of it.

$ vim uEnv.txt

And write the following commands in it.

bootpart=0:1
devtype=mmc
bootdir=
bootfile=zImage
bootpartition=mmcblk0p2
console=ttyS0,115200n8
loadaddr=0x82000000
fdtaddr=0x88000000
set_mmc1=if test $board_name = A33515BB; then setenv bootpartition mmcblk1p2; fi
set_bootargs=setenv bootargs console=${console} root=/dev/${bootpartition} rw rootfstype=ext4 rootwait
uenvcmd=run set_mmc1; run set_bootargs;run loadimage;run loadfdt;printenv bootargs;bootz ${loadaddr} - ${fdtaddr}

At the end of this series, you will fully understand what these are. But basically:

the console name is set to ttyS0 and baud rate to 115200.
the Linux kernel name is defined as zImage.
the address that Linux kernel image will be placed is set to 0x82000000 and the address that device tree blob will be placed to 0x88000000.
set the boot environment and load the Linux kernel with bootz command.

Save it and then keep this file in mind as being MLO and u-boot.img.

That's it. You've produced the three components related to bootloader stage. In next post, I will interest with Linux kernel itself.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part 1

Can Gulmez — Sun, 12 Apr 2026 12:53:51 +0000

In today, I'm beginning a new series about embedded Linux development. I'll show that how to build an end-to-end embedded Linux system from scratch by hand.

I'll fetch the associated every stuffs from source code and then build the corresponding outputs.

I will target the BeagleBone Black Rev C board. I will compile the everything for that board. So you need the following things for this series:

BeagleBone Black Rev C
USB Mini-B to USB-A cable
FTDI FT232R converter
SD card

Overall, embedded Linux development consists of four components:

Toolchain
Bootloader
Linux kernel
Rootfs

In this post, I will explain the toolchain that I need for all development sequence.

The toolchain is the first element of embedded Linux and the starting point of the project.

A toolchain is the set of tools that compiles source code into executables that can run on your target device, and includes many binaries for the different purposes. Usually, toolchains for Linux are based on components from the GNU project. A standard GNU toolchain consists of three main components:

Binutils is a set of tools to generate and manipulate binaries for a given architecture. Common binaries: as, ld, ar, randlib, objdump, readelf, size, nm, strings, strip, etc.
GCC is the main compiler.
C library is used to interract with the kernel. The programming interface to the UNIX operating system is defined in the C language, which is defined by the POSIX standards. The C library is the implementation of the interface.

In here, there are two types of toolchain:

Native: This toolchain runs on the same type of system.
Cross: This toolchain run on a different type of system than the target.

Almost all embedded Linux development is done using a cross development toolchain. Because doing embedded development, there is always a split between:

The host, the development workstation
The target, which is the embedded system

They are connected by various means: almost always a serial line for debugging purposes, frequently a network connection, sometimes a JTAG interface for low-level stuffs.

Many UNIX/Linux toolchains rely on architecture tuple names to identify machines. You probably compiled many programs on your host already and used the gcc command. But it's actually a shorthand. You can exactly see it with:

$ gcc -dumpmachine
x86_64-linux-gnu

Other examples: arm-linux-gnueabihf, mips64el-linux-gnu, arm-none-eabi- etc.

These tuples are 3 or 4 parts:

The architecture name: arm, riscv, mips64el, etc.
Optionally, a vendor name, which is free-form string.
An operating system name, or none when not targeting an operating system.

Of course, these are the pre-built toolchains. If you want, you can also create your own toolchain with crosstool-ng. It's another post topic. But shortly, when building a toolchain, the ABI used to generate binaries needs to be defined. ABI, Application Binary Interface, defines the calling conventions (how function arguments are passed, how the return value is passed, how system calls are made or so on) and the organization of structures. All binaries in a system are typically compiled with the same ABI, and the kernel must understand this ABI.

Anyway, I gave you the enough theoretical toolchain background. Let's go with our concern.

Which toolchain should be used for BeagleBone Black?

You have to know the used ARM processor in here. BeageBone Black has AM335x Sitara processor which is based on ARM-A8 (ARMv7), 32-bit architecture. So the toolchain for that is the gcc-arm-linux-gnueabihf.

The first thing in implementing embedded Linux is to install it.

$ sudo apt install gcc-arm-linux-gnueabihf

After that validate it.

$ arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

That's it. You have the required toolchain and ready to go with the bootloader.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

POSIX Shared Memory

Can Gulmez — Wed, 08 Apr 2026 12:47:19 +0000

POSIX shared memory allows to us to share a mapped region between unrelated processes without needing to create a corresponding file.

Linux uses a dedicated tmpfs file system mounted under the directory /dev/shm. This file system has kernel persistance - the shared memory objects that it contains will persists even if no process currently has them open, but they will be lost if the system is shut down.

To use a POSIX shared memory object, we perform two steps:

Use the shm_open() function to open an object with a specified name. The shm_open() function is analogous to the open() system call. It either creates a new shared memory object or opens an existing object. As its function result, shm_open() returns a file descriptor referring to the object.
Pass the file descriptor obtained in the previous step in a call to mmap() that specifies MAP_SHARED in the flags argument. This maps the shared memory object into the process's virtual address space.

#include <sys/mman.h>
#include <sys/stat.h>        /* For mode constants */
#include <fcntl.h>           /* For O_* constants */

int shm_open(const char *name, int oflag, mode_t mode);
int shm_unlink(const char *name);

The name argument identifies the shared memory object to be created or opened. The oflags argument is a mask of bits of O_* as being in open() system call.

At any point, we can apply fstat() to the file descriptor returned by shm_open() in order to obtain a stat structure whose contain information about the shared memory object.

Example of creating a POSIX shared memory is here.

After created the memory object, we of course want to read and write the data into that. Data reading program is here and writing program is here.

SUSv3 requires that POSIX shared memory objects have at least kernel persistence; that is, they continue to exist until they are explicitly removed or the system is rebooted. When a shared memory object is no longer required, it should be removed using shm_unlink(). The example program of its usage is here.

In summary, a POSIX shared memory object is used to share a region of memory between unrelated processes without creating an underlying disk file. To do this, we replace the call to open() that normally precedes mmap() with a call to shm_open(). The shm_open() call creates a file in a memory-based file system, and we can employ traditional file descriptor system calls to perform various operations on this virtual file. In particular, ftruncate() must be used to set the size of the shared memory object, since initially it has a length of zero.

Flashing and Debugging A Firmware in Detail

Can Gulmez — Tue, 10 Mar 2026 20:38:32 +0000

In this tutorial, I will inspect, flash and debug a firmware written for STM32F446RE microcontroller. To accomplish this, we need some dedicated tools:

openocd
arm-none-eabi-*
gdb-multiarch

openocd is the primarily tool that we have to get. It's used as bridge between your host machine and debugger hardware. (I'm using use ST-Link hardware in this time). I will use it to connect to the debugger hardware. arm-none-eabi-* tools are the ARM toolchain used in development of the firmware. gdb-multiarch is the debugger too.

You can get these tools:

$ sudo apt install openocd gcc-arm-none-eabi gdb-multiarch

Note: I'm on Ubuntu 24.04, gcc-arm-none-eabi tools don't include the gdb debugger like arm-none-eabi-gdb. So that gdb-multiarch is being installed externally. On some distribution, the gdb debugger comes with gcc-arm-none-eabi.

Suppose that I have a firmware called "firmware.elf" and wanna inspect it as first step.

The first thing that you should do probably is to determine the firmware itself:

$ file firmware.elf
firmware.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped

The file command simply outputs the firmware properties like the endiannes, architecture, or so on. You can see easily that this firmware was written for 32-bit ARM Cortex.

We can see also the section sizes (in bytes) of the firmware with arm-none-eabi-size command:

$ arm-none-eabi-size firmware.elf
   text    data     bss     dec     hex filename
   5252      20    1732    7004    1b5c firmware.elf

If you are not familiar with sections of the executables, I've wrote many tutorials that explains the ELF executable. You can look at there.

If you exactly wanna see the contents of the firmware, arm-none-eabi-objdump is the primarily tool for that:

$ arm-none-eabi-objdump -j .text -d firmware.elf

firmware.elf:     file format elf32-littlearm


Disassembly of section .text:

(...)

0800079c <main>:
 800079c:   b500        push    {lr}
 800079e:   b091        sub sp, #68 @ 0x44
 80007a0:   f000 f8ac   bl  80008fc <HAL_Init>
 80007a4:   f000 f82c   bl  8000800 <configOscClk>
 80007a8:   f000 f844   bl  8000834 <configDebugPort>
 80007ac:   4911        ldr r1, [pc, #68]   @ (80007f4 <main+0x58>)
 80007ae:   4d12        ldr r5, [pc, #72]   @ (80007f8 <main+0x5c>)
 80007b0:   4c12        ldr r4, [pc, #72]   @ (80007fc <main+0x60>)
 80007b2:   4668        mov r0, sp
 80007b4:   f7ff ff08   bl  80005c8 <strcpy>
 80007b8:   4668        mov r0, sp
 80007ba:   f7ff ff81   bl  80006c0 <strlen>
 80007be:   f04f 33ff   mov.w   r3, #4294967295 @ 0xffffffff
 80007c2:   b282        uxth    r2, r0
 80007c4:   4669        mov r1, sp
 80007c6:   480d        ldr r0, [pc, #52]   @ (80007fc <main+0x60>)
 80007c8:   f000 fdc2   bl  8001350 <HAL_UART_Transmit>
 80007cc:   4629        mov r1, r5
 80007ce:   4668        mov r0, sp
 80007d0:   f7ff fefa   bl  80005c8 <strcpy>
 80007d4:   4668        mov r0, sp
 80007d6:   f7ff ff73   bl  80006c0 <strlen>
 80007da:   f04f 33ff   mov.w   r3, #4294967295 @ 0xffffffff
 80007de:   b282        uxth    r2, r0
 80007e0:   4669        mov r1, sp
 80007e2:   4620        mov r0, r4
 80007e4:   f000 fdb4   bl  8001350 <HAL_UART_Transmit>
 80007e8:   f44f 707a   mov.w   r0, #1000   @ 0x3e8
 80007ec:   f000 f8b2   bl  8000954 <HAL_Delay>
 80007f0:   e7ec        b.n 80007cc <main+0x30>
 80007f2:   bf00        nop
 80007f4:   0800146c    .word   0x0800146c
 80007f8:   08001489    .word   0x08001489
 80007fc:   20000084    .word   0x20000084

(...)

For example, you see the main() function in .text section of the firmware. At left, the address of the machine code were being displayed. At center, you see the machine code corresponding to assembly instructions that is at right side.

Inspecting the contents of ELF executable is huge topic. It has many variants and view-of-points in there.

"Flashing" term means writing the dedicated sections of the firmware into the flash memory area of the microcontroller. It's done with many different ways. But I will show you openocd tool.

In here, I have to define that how exactly does openocd work. It actually creates a server into the host machine with given configuration files. After starting the server session, you need to connect to that server over telnet or gdb.

Let's do it. Firstly, connect the microcontroller to the host machine. Then open a terminal session and type this command:

$ openocd -f interface/stlink.cfg -f target/stm32f4x.cfg

In here, I gave the two configuration files. First is the interface. As I said, I use the ST-Link connection. Second is the target file. It defines the target architecture. The openocd comes a bunch of configuration files. So search it and find the appropriate configuration files.

You will see something like this:

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
Info : STLINK V2J33M25 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.224656
Info : [stm32f4x.cpu] Cortex-M4 r0p1 processor detected
Info : [stm32f4x.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 3333
Info : Listening on port 3333 for gdb connections

The openocd attached the 4444 port to telnet and 3333 port to gdb. So that I will bind the 3333 port in the gdb session.

Secondly, open the second terminal and type:

$ gdb-multiarch firmware.elf

At the moment, you are in the gdb session. In here, bind to the 3333 port:

(gdb) target remote localhost:3333

For now, you are in the control and responsible for the all flashing and debugging operations.

To flash the firmware, use these commands:

(gdb) monitor reset halt
(gdb) load
(gdb) monitor reset halt

There are tons of commands you can type in the gdb session. We can split these commands in two categories. monitor commands directly are run by the openocd command. Other commands are run by the gdb itself.

load is the main command to flash the firmware. Before and after that command, resetting and halting the CPU execution is good practice. Output will be like:

Loading section .isr_vector, size 0x1c4 lma 0x8000000
Loading section .text, size 0x126c lma 0x8000200
Loading section .rodata, size 0x4c lma 0x800146c
Loading section .ARM, size 0x8 lma 0x80014b8
Loading section .init_array, size 0x4 lma 0x80014c0
Loading section .fini_array, size 0x4 lma 0x80014c4
Loading section .data, size 0xc lma 0x80014c8
Start address 0x08001400, load size 5272
Transfer rate: 9 KB/sec, 753 bytes/write.

That means that the firmware successfully was flashed 🥳.

If you just wanna flash the firmware and not debugging, this following command is enough:

$ openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c "program firmware.elf verify reset exit"

Instead of dealing with two terminal sessions, above command is just the one-step operation.

The main reason opening the second gdb session is to make the debugging. If you did the debugging previously, you will be familiar with these commands:

(gdb) break main
(gdb) continue
(gdb) next
(gdb) finish
(gdb) print var
(gdb) x/16wx *ptr
(gdb) set var
(gdb) list

The debugging operations are huge and will not fit into a single tutorial as you guest. So that I don't wanna dive into the these and other operations. But I wanna give you a good reference: The Art of Debugging with GDB, DDD, and Eclipse written by Norman Matloff and Peter Jay Salzman.

Until here, I gave a overall explanation the end-to-end pipeline. I'll explain the other stuffs in further.

Simple Code Injection into ELF Executable

Can Gulmez — Tue, 03 Mar 2026 12:44:18 +0000

In this tutorial, I will explain an code injection technique into ELF executable.

Firstly, you need to understand the ELF executable, its contents, sections, symbol table or so on. I've written a dedicated article previously. So if you don't have any information about ELF, please read it firstly and then come here again.

Let's say we have the following source file:

/**
 * Simple Code Injection
 */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
    int i, num;

    num = 10;

    for (i = 0; i < num; i++)
    {
        printf("#%d\n", i);
    }

    return EXIT_SUCCESS;
}

Compile this source file and then run it:

$ gcc main.c -o main ; ./main

After that, you will see:

#0
#1
#2
#3
#4
#5
#6
#7
#8
#9

In here, I will change the num = 10 to num = 5 so that the output will be #0 to #4.

To accomplish this, I need to find the corresponding machine instruction/s. According to your background, you need to know that num variable will be in the .text section of ELF executable. Because it is the local variable. To display the .text section of the program, objdump is the primarily tool:

$ objdump -j .text -d main

The output will be as following:

(...)

0000000000001149 <main>:
    1149:   f3 0f 1e fa             endbr64
    114d:   55                      push   %rbp
    114e:   48 89 e5                mov    %rsp,%rbp
    1151:   48 83 ec 20             sub    $0x20,%rsp
    1155:   89 7d ec                mov    %edi,-0x14(%rbp)
    1158:   48 89 75 e0             mov    %rsi,-0x20(%rbp)
    115c:   c7 45 fc 0a 00 00 00    movl   $0xa,-0x4(%rbp)
    1163:   c7 45 f8 00 00 00 00    movl   $0x0,-0x8(%rbp)
    116a:   eb 1d                   jmp    1189 <main+0x40>
    116c:   8b 45 f8                mov    -0x8(%rbp),%eax
    116f:   89 c6                   mov    %eax,%esi
    1171:   48 8d 05 8c 0e 00 00    lea    0xe8c(%rip),%rax        # 2004 <_IO_stdin_used+0x4>
    1178:   48 89 c7                mov    %rax,%rdi
    117b:   b8 00 00 00 00          mov    $0x0,%eax
    1180:   e8 cb fe ff ff          call   1050 <printf@plt>
    1185:   83 45 f8 01             addl   $0x1,-0x8(%rbp)
    1189:   8b 45 f8                mov    -0x8(%rbp),%eax
    118c:   3b 45 fc                cmp    -0x4(%rbp),%eax
    118f:   7c db                   jl     116c <main+0x23>
    1191:   b8 00 00 00 00          mov    $0x0,%eax
    1196:   c9                      leave
    1197:   c3                      ret

Which machine instruction/s corresponds to num = 10? You need to know reading the assembly instructions in here. The answer is the movl $0xa,-0x4(%rbp) assembly instruction. Because the stack pointer of the program was enlarged by 4 bytes (int holds 4 bytes of memory) to lower address and put the immediate 0xA value. So that I need to change the 0xA value to 0x5.

After the found required assembly instruction, I need to determine the memory address of it. If you look at center column, the machine instruction is c7 45 fc 0a 00 00 00. In here:

c7: the opcode of movl register
45 fc: the displacement of -0x4(%rbp)
0a 00 00 00: the immediate value, 0xA (little-endian)

c7 byte resides at 0x115c address so that 0a byte at 0x115f.

To change that byte, I'm gonna use hexedit program:

$ hexedit ./main

You will see:

After that, you move to 0x115F address and change the 0x0A value to 0x05. Save the changes and then run the program again. You will see:

#0
#1
#2
#3
#4

That's it. You injected the new code in the ELF executable 🥳.

This technique is simple and powerful. But there are some limitations. The most important one is that you should not shift the byte addresses, just replace it. If you wanna change the entire ELF executable addresses, you need the other techniques. That's the next article's topic.

ELF Executable Analysis in Detail

Can Gulmez — Tue, 24 Feb 2026 20:03:28 +0000

In everyday, we run some kind of programs to handle our works. There are many type of programs, GUIs, CLIs, TUIs or so on. But at low level, there are two kind of program formats: PE (Portable Executable) for Windows and ELF (Executable and Linkable Format) for Linux.

In this tutorial, I will explain the ELF executables in detail.

Firstly, let's start with the overall layout:

As you see, an ELF executable consists of four layers:

Executable Header
Program Headers
Sections
Section Headers

Executable Header

Every ELF file starts with an executable header, which is just a structured series of bytes telling you that it's an ELF file, what kind of ELF file it is, and where in the file to find all the other contents. It's defined as follow in /usr/include/elf.h:

In here:

e_ident: The executable header starts with a 16-byte array. First 4-byte, magic value, identifying the file as an ELF binary.
e_type: The type of the executable. For example REL means relocatable object file, EXEC means executable binary and DYN means dynamic libraries.
e_machine: The architecture that the executable is intended to run on.
e_version: The version of the ELF specification (always 1, I really don't know why it exists 😂).
e_entry: The virtual address at which execution should start.
e_phoff, e_shoff: The file offsets to the beginning of the program header table and the section header table.
e_flags: The flags specific to the architecture for which the binary is compiled (typically 0 for x86_64).
e_ehsize: The size of the executable header, in bytes (for 64-bit systems, it's always 64).

You can see the executable header with this command:

$ readelf -h ./prog
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Position-Independent Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x1400
  Start of program headers:          64 (bytes into file)
  Start of section headers:          135496 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         13
  Size of section headers:           64 (bytes)
  Number of section headers:         29
  Section header string table index: 28

Section Headers

The code and data in an ELF binary are logically divided into continuous nonoverlapping chunks called sections. Sections don't have any predetermined structure; instead, the structure of each section varies depending on the contents. So every section is described in section header table. It's defined as follow:

In here:

sh_name: The index of the sections.
sh_type: Every section has a type, indicated by an integer field. Common types: PROBITS for machine instructions, SYMTAB for static symbol table, DYNSYM for dynamic symbol table, STRTAB for string tables, REL(A) for relocation entries used by the linker, DYNAMIC for information needed for dynamic linking or so on.
sh_flags: The section flags. Common flags: W means the section is writable, A means the content of the section are to be loaded into memory when executing the executable, X means the section is executable.
sh_addr, sh_offset, sh_size: The virtual address, file offset (in bytes from the start
of the file), and size (in bytes) of the sections.
sh_link: Sometimes, there are relationships between sections. This field keeps the index count of the related sections.
sh_info: Additional information about sections.
sh_addralign: Some sections may need to be aligned in memory in a particular way for efficiency of memory accesses. The values 0 and 1 are reserved to indicate no special alignment needs.
sh_entsize: Some sections contain a table of well-defined data structures. For such sections, this field indicates the size in bytes of each entry in the table. When the field is unused, it is set to zero.

You can see the section headers with this command:

$ readelf --sections --wide ./prog
There are 29 section headers, starting at offset 0x21148:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        0000000000000318 000318 00001c 00   A  0   0  1
  [ 2] .note.gnu.property NOTE            0000000000000338 000338 000030 00   A  0   0  8
  [ 3] .note.gnu.build-id NOTE            0000000000000368 000368 000024 00   A  0   0  4
  [ 4] .note.ABI-tag     NOTE            000000000000038c 00038c 000020 00   A  0   0  4
  [ 5] .gnu.hash         GNU_HASH        00000000000003b0 0003b0 000028 00   A  6   0  8
  [ 6] .dynsym           DYNSYM          00000000000003d8 0003d8 000378 18   A  7   1  8
  [ 7] .dynstr           STRTAB          0000000000000750 000750 00016d 00   A  0   0  1
  [ 8] .gnu.version      VERSYM          00000000000008be 0008be 00004a 02   A  6   0  2
  [ 9] .gnu.version_r    VERNEED         0000000000000908 000908 000080 00   A  7   2  8
  [10] .rela.dyn         RELA            0000000000000988 000988 0000d8 18   A  6   0  8
  [11] .rela.plt         RELA            0000000000000a60 000a60 0002d0 18  AI  6  24  8
  [12] .init             PROGBITS        0000000000001000 001000 00001b 00  AX  0   0  4
  [13] .plt              PROGBITS        0000000000001020 001020 0001f0 10  AX  0   0 16
  [14] .plt.got          PROGBITS        0000000000001210 001210 000010 10  AX  0   0 16
  [15] .plt.sec          PROGBITS        0000000000001220 001220 0001e0 10  AX  0   0 16
  [16] .text             PROGBITS        0000000000001400 001400 018c54 00  AX  0   0 16
  [17] .fini             PROGBITS        000000000001a054 01a054 00000d 00  AX  0   0  4
  [18] .rodata           PROGBITS        000000000001b000 01b000 002ee8 00   A  0   0 16
  [19] .eh_frame_hdr     PROGBITS        000000000001dee8 01dee8 0005fc 00   A  0   0  4
  [20] .eh_frame         PROGBITS        000000000001e4e8 01e4e8 001914 00   A  0   0  8
  [21] .init_array       INIT_ARRAY      0000000000020cc0 020cc0 000008 08  WA  0   0  8
  [22] .fini_array       FINI_ARRAY      0000000000020cc8 020cc8 000008 08  WA  0   0  8
  [23] .dynamic          DYNAMIC         0000000000020cd0 020cd0 000200 10  WA  7   0  8
  [24] .got              PROGBITS        0000000000020ed0 020ed0 000130 08  WA  0   0  8
  [25] .data             PROGBITS        0000000000021000 021000 000010 00  WA  0   0  8
  [26] .bss              NOBITS          0000000000021020 021010 000010 00  WA  0   0 32
  [27] .comment          PROGBITS        0000000000000000 021010 00002b 01  MS  0   0  1
  [28] .shstrtab         STRTAB          0000000000000000 02103b 00010a 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), l (large), p (processor specific)

Sections

In previous chapter, you see that the ELF executable has a set of sections at which each section has a special meaning. For now, let me explain these:

.init and .fini: The .init section contains machine code that performs initialization before the main() function and .fini runs after it.
.text: This section is where the main code of the executable resides that we've wrote. It's the main concern for binary analysis or reverse engineering efforts.
.bss, .data, .rodata: There sections are where the program variables live. According to the declaration style, the variable goes into one of the three sections. For example, initialized global variables live in .data, uninitialized global variables live in .bss and constant variables live in .rodata. Don't forget that the local variables go in the stack, so .text, not into one of these sections.
.rel.* and .rela.*: These sections contain the information used by the linker for performing relocations.
.dynamic: It contains the "road map" for dynamic linker when loading and setting up the ELF executable.

As an example, you can inspect a specific section with this command:

$ objdump -j .text -d ./prog

./prog:     file format elf64-x86-64

Disassembly of section .text:

0000000000001400 <.text>:
    1400:       f3 0f 1e fa             endbr64
    1404:       31 ed                   xor    %ebp,%ebp
    1406:       49 89 d1                mov    %rdx,%r9
    1409:       5e                      pop    %rsi
    140a:       48 89 e2                mov    %rsp,%rdx
    140d:       48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
    1411:       50                      push   %rax
    1412:       54                      push   %rsp
    1413:       45 31 c0                xor    %r8d,%r8d
    1416:       31 c9                   xor    %ecx,%ecx
    1418:       48 8d 3d 48 15 00 00    lea    0x1548(%rip),%rdi        # 2967 <rand@plt+0x1577>
    141f:       ff 15 b3 fb 01 00       call   *0x1fbb3(%rip)        # 20fd8 <rand@plt+0x1fbe8>
    1425:       f4                      hlt
    1426:       66 2e 0f 1f 84 00 00    cs nopw 0x0(%rax,%rax,1)
    142d:       00 00 00 
    1430:       48 8d 3d d9 fb 01 00    lea    0x1fbd9(%rip),%rdi        # 21010 <rand@plt+0x1fc20>
    1437:       48 8d 05 d2 fb 01 00    lea    0x1fbd2(%rip),%rax        # 21010 <rand@plt+0x1fc20>
    143e:       48 39 f8                cmp    %rdi,%rax
    1441:       74 15                   je     1458 <rand@plt+0x68>
    1443:       48 8b 05 96 fb 01 00    mov    0x1fb96(%rip),%rax        # 20fe0 <rand@plt+0x1fbf0>
    144a:       48 85 c0                test   %rax,%rax
    144d:       74 09                   je     1458 <rand@plt+0x68>
    144f:       ff e0                   jmp    *%rax
    1451:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)

(...)

Program Headers

The program header table provides a segment view of the binary, as opposed to the section view provided by the section header table. It's defined as follow:

In here:

p_type: The type of segments. Common types: LOAD means the segment are intended to be loaded into memory, INTERP means the segment contains .interp section providing name of the interpreter that is to be used to load the executable, DYNAMIC means the segment contains the .dynamic section, which tells the interpreter how to parse and prepare the binary for execution, PHDR means the segment encompasses the program header table.
p_flags: The runtime access permissions for the segments. Common flags: X means executable, R means readable, W means writable or so on.
p_offset, p_vaddr, p_paddr, p_filesz, p_memsz: These equals to sh_offset, sh_addr, sh_size fields in the section headers.
p_align: It's equal to sh_addralign field.

You can see the program headers with this command:

$ readelf --segments --wide ./prog

Elf file type is DYN (Position-Independent Executable file)
Entry point 0x1400
There are 13 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000000000040 0x0000000000000040 0x0002d8 0x0002d8 R   0x8
  INTERP         0x000318 0x0000000000000318 0x0000000000000318 0x00001c 0x00001c R   0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x000d30 0x000d30 R   0x1000
  LOAD           0x001000 0x0000000000001000 0x0000000000001000 0x019061 0x019061 R E 0x1000
  LOAD           0x01b000 0x000000000001b000 0x000000000001b000 0x004dfc 0x004dfc R   0x1000
  LOAD           0x020cc0 0x0000000000020cc0 0x0000000000020cc0 0x000350 0x000370 RW  0x1000
  DYNAMIC        0x020cd0 0x0000000000020cd0 0x0000000000020cd0 0x000200 0x000200 RW  0x8
  NOTE           0x000338 0x0000000000000338 0x0000000000000338 0x000030 0x000030 R   0x8
  NOTE           0x000368 0x0000000000000368 0x0000000000000368 0x000044 0x000044 R   0x4
  GNU_PROPERTY   0x000338 0x0000000000000338 0x0000000000000338 0x000030 0x000030 R   0x8
  GNU_EH_FRAME   0x01dee8 0x000000000001dee8 0x000000000001dee8 0x0005fc 0x0005fc R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
  GNU_RELRO      0x020cc0 0x0000000000020cc0 0x0000000000020cc0 0x000340 0x000340 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt 
   03     .init .plt .plt.got .plt.sec .text .fini 
   04     .rodata .eh_frame_hdr .eh_frame 
   05     .init_array .fini_array .dynamic .got .data .bss 
   06     .dynamic 
   07     .note.gnu.property 
   08     .note.gnu.build-id .note.ABI-tag 
   09     .note.gnu.property 
   10     .eh_frame_hdr 
   11     
   12     .init_array .fini_array .dynamic .got

Until here, I gave you the overall, a bit detailed, presentation about the ELF executable. For next articles, I will dive into the binary analysis techniques in deeply for Linux.

Resource:

Andriesse D., Practical Binary Analysis, no starch press, San Francisco.

How to build a firmware using Makefile?

Can Gulmez — Sun, 21 Dec 2025 12:46:38 +0000

In embedded programming, we trust IDEs like STM32CubeIDE, Keil or so on. These IDEs give us just some buttons and UIs to build, flash, and debug the source code that we've written for a MCU. But, I think that every engineer that works on this field have to know that how these steps are made by hand.

In this tutorial, I will show building a firmware written for STM32F446RE MCU with just using a single Makefile.

Below is the project directory:

$ tree
.
├── bin/
├── drivers/
│   ├── CMSIS/
│   ├── STM32F446RETX_FLASH.ld
│   └── STM32F4xx_HAL_Driver/
├── lib/
├── Makefile
└── src/
    ├── it.c
    ├── main.c
    ├── main.h
    └── peripheral.c

Firstly, which libraries do we need to have?

HAL library
CMSIS library
Linker script
Startup/system code
arm-none-eabi-* tools

I've put the all required libraries/scripts into /drivers directory. Please download these using:

$ git clone --recurse-submodules https://github.com/STMicroelectronics/STM32CubeF4.git
$ sudo apt install gcc-arm-none-eabi

In here, HAL library is used to program the peripherals and CMSIS for ARM-Cortex itself. These are the most important libraries that we have to get.

Apart from that, we also need some special files. First is the linker script. It includes the memory layout of microcontroller. Sometimes, it comes from above command. But if you cannot find it there, please install it externally. Another file is the startup code. It's written in Assembly language. As its name suggests, it's the first code that runs in microcontroller. Basically, it includes the Reset_Handler and a branch that jumps into main() function in your source code. Also system code includes the some generic and general definitions.

After downloaded and explained the required ones, Let's write the Makefile step by step:

1. Toolchain definitions

CC              := arm-none-eabi-gcc
OBJCOPY         := arm-none-eabi-objcopy
SIZE            := arm-none-eabi-size
RM              := rm -f
FILE            := file

2. MCU-specific definitions

DEVICE_FAMILY        := STM32F4xx
DEVICE_MODEL         := STM32F446xx
DEVICE_VARIANT       := STM32F446RETx

3. Compiler and linker flags

CORTEX_FLAGS         := -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard
COMMON_FLAGS         := -g3 -Os -ffunction-sections -fdata-sections -Wall
AS_FLAGS             := -x assembler-with-cpp

In here, we've defined some flags:

-mthumb means that the firmware uses thumb (16-bit) instruction set.
-mcpu=cortex-m4 means the ARM-Cortex series itself.
-mfpu=fpv4-sp-d16 and -mfloat-abi=hard means that floating-point operations can be done in the firmware.

4. Include paths

MAIN_INC        := ./src
CMSIS_INC       := ./drivers/CMSIS/Include
CMSIS_DEV_INC   := ./drivers/CMSIS/Device/ST/STM32F4xx/Include
HAL_INC         := ./drivers/STM32F4xx_HAL_Driver/Inc
CMSIS_DSP_INC   := ./drivers/CMSIS/DSP/Include

In here, we specified the header files that are used in the source code.

5. Source and special files

MAIN_SRC        := $(wildcard ./src/*.c)
HAL_SRC         := $(wildcard ./drivers/STM32F4xx_HAL_Driver/Src/*.c)
SYSTEM_SRC      := ./drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx.c
STARTUP_CODE    := ./drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc/startup_stm32f446xx.S
LINKER_SCRIPT   := ./drivers/STM32F446RETX_FLASH.ld

6. Sorthands and build definitions

DEFINES         := -D$(DEVICE_FAMILY) -D$(DEVICE_MODEL) -D$(DEVICE_VARIANT) \
                        -DUSE_HAL_DRIVER

SOURCES         := $(MAIN_SRC) $(HAL_SRC) $(SYSTEM_SRC)
OBJECTS         := $(notdir $(patsubst %.c,%.o,$(SOURCES))) startup_stm32f446xx.o
INCLUDES            := -I$(MAIN_INC) -I$(CMSIS_DEV_INC) -I$(CMSIS_INC) -I$(HAL_INC) \
                        -I$(CMSIS_DSP_INC)

CFLAGS          := $(CORTEX_FLAGS) $(COMMON_FLAGS) $(DEFINES) $(INCLUDES)
AFLAGS          := $(CORTEX_FLAGS) $(AS_FLAGS) $(DEFINES) $(INCLUDES)
LDFLAGS         := $(CORTEX_FLAGS) -T $(LINKER_SCRIPT) \
                        -Wl,--gc-sections,--relax --specs=nano.specs --specs=nosys.specs \
                    -Wl,--start-group -lc -lm -lnosys -Wl,--end-group

In here, I mostly did the string operations and manipulations. But some points are interesting and need some explanations:

Firstly, I've grouped the sources and libraries and converted the source file suffixes into object file formats.
Also, I've created three total flags that will be used for compiling, assembling, and linking phases.
In linker flags, I put the linker script. As you noticed, this step will be done after the compiling the source files. I also linked the some libraries. -lc is the standard C library. In firmware, we use often string manipulation functions (strlen(), strcat(), strcpy() or so on), snprint(), memset(), or similar ones. -lm is the math library as you know. -lnosys means that I'm just implementing the bare-metal firmware, there is no such as kernel or fully OS.

7. Output files

FIRMWARE_ELF    := firmware.elf
FIRMWARE_BIN    := firmware.bin

Generally, we use the ELF file when flashing and debugging. ELF executable includes the both machine code, metadata, debug information, symbol table or similar stuffs. In contrast, BIN executable just includes the machine code. If you look at the size of both, you will use the ELF executable is much bigger!

8. The recipe

.PHONY: all

all:
    @echo "-------------------------------------"
    @echo "----- Building the source files -----"
    @echo "-------------------------------------"
    @$(CC) $(AFLAGS) -c $(STARTUP_CODE)
    @$(CC) $(CFLAGS) -c $(SOURCES)

    @echo "\n------------------------------------"
    @echo "----- Linking the object files -----"
    @echo "------------------------------------"
    @$(CC) $(LDFLAGS) $(OBJECTS) -o $(FIRMWARE_ELF)
    @$(OBJCOPY) -O binary $(FIRMWARE_ELF) $(FIRMWARE_BIN)
    @$(RM) $(OBJECTS)

    @echo "\n-------------------------------------"
    @echo "----- The firmware memory usage -----"
    @echo "-------------------------------------"
    @$(SIZE) $(FIRMWARE_ELF)

    @echo "\n-------------------------------------"
    @echo "----- The firmware binary format ----"
    @echo "-------------------------------------"
    @$(FILE) $(FIRMWARE_ELF)

Lastly, run the Makefile:

$ make

That's it 🥳🥳🥳. You've built the both firmware.elf and firmware.bin.

You are ready to flash the built firmware into microcontroller with this or similar command (over ST-Link connection):

$ openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c "program firmware.elf verify reset exit"