Forem: Can Gulmez

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"

What exactly is "program" and what does it include?

Can Gulmez — Mon, 08 Dec 2025 14:05:17 +0000

In this article, I wanna talk about program and process terms that are fundamental elements in computer-science. This two terms generally are used exchangeably. But in technically, both are so different. Let's begin with explaining these terms and then deeply see the what it includes:

A program is a file containing a range of information that describes how to construct a "process" at run time [1].
A process is an instance of an executing program [1].

These are the formal definations. If I try to express with my words:

A program (or binary) is a file that includes the machine code + metadata + debug information (if the program compiled with -g flag) and process is a abstraction point that kernel creates and then allocates hardware resources like CPU, RAM, memory or similar ones.

First thing that you should know is the program format. In recently, there are two type of program formats that the compilers generate:

ELF (Executable and Linkable Format)
PE (Portable Executable)

Executable and Linkable Format

ELF is the standard format for UNIX/Linux systems and PE for Windows. I'm currently on Ubuntu 24.10 (x86_64) so that I will explain and use ELF format. As you guest, I don't know really PE format. But there is a good reference handbook that you can look at. It's "Practical Binary Analysis" written by Dennis Andriesse.

After explained the program formats, right now, let's look at the inside of the program:

In general, any program includes these:

Executable header
Program headers
Sections
Section headers

Every ELF file starts with an executable header, which is just a structured series of bytes telling you that it's and ELF file, what kind of ELF file it is, and where in the files to find all the other contents [2].

You can exactly see the content of this header with readelf command:

$ readelf -h ./copy
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:               0x1160
  Start of program headers:          64 (bytes into file)
  Start of section headers:          17496 (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:         37
  Section header string table index: 36

In there, first four digits (7f 45) of Magic series define the program format. You will see the probably different series if you are on Windows. Other properties is the self-explaining.

The code and data in an ELF program are logically divided into sections. Each section includes a specific part of your source code. And the sections in the binary are contained in the section header table. Some sections are used to execute the machine instructions and some for other information (like symbol table used by debugger). Let's look at the section headers:

$ readelf --sections --wide ./copy
There are 37 section headers, starting at offset 0x4458:

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 000180 18   A  7   1  8
  [ 7] .dynstr           STRTAB          0000000000000558 000558 0000d3 00   A  0   0  1
  [ 8] .gnu.version      VERSYM          000000000000062c 00062c 000020 02   A  6   0  2
  [ 9] .gnu.version_r    VERNEED         0000000000000650 000650 000030 00   A  7   1  8
  [10] .rela.dyn         RELA            0000000000000680 000680 0000d8 18   A  6   0  8
  [11] .rela.plt         RELA            0000000000000758 000758 0000d8 18  AI  6  24  8
  [12] .init             PROGBITS        0000000000001000 001000 00001b 00  AX  0   0  4
  [13] .plt              PROGBITS        0000000000001020 001020 0000a0 10  AX  0   0 16
  [14] .plt.got          PROGBITS        00000000000010c0 0010c0 000010 10  AX  0   0 16
  [15] .plt.sec          PROGBITS        00000000000010d0 0010d0 000090 10  AX  0   0 16
  [16] .text             PROGBITS        0000000000001160 001160 00043a 00  AX  0   0 16
  [17] .fini             PROGBITS        000000000000159c 00159c 00000d 00  AX  0   0  4
  [18] .rodata           PROGBITS        0000000000002000 002000 000040 00   A  0   0  4
  [19] .eh_frame_hdr     PROGBITS        0000000000002040 002040 000034 00   A  0   0  4
  [20] .eh_frame         PROGBITS        0000000000002078 002078 0000a8 00   A  0   0  8
  [21] .init_array       INIT_ARRAY      0000000000003d78 002d78 000008 08  WA  0   0  8
  [22] .fini_array       FINI_ARRAY      0000000000003d80 002d80 000008 08  WA  0   0  8
  [23] .dynamic          DYNAMIC         0000000000003d88 002d88 0001f0 10  WA  7   0  8
  [24] .got              PROGBITS        0000000000003f78 002f78 000088 08  WA  0   0  8
  [25] .data             PROGBITS        0000000000004000 003000 000010 00  WA  0   0  8
  [26] .bss              NOBITS          0000000000004020 003010 000010 00  WA  0   0 32
  [27] .comment          PROGBITS        0000000000000000 003010 00002b 01  MS  0   0  1
  [28] .debug_aranges    PROGBITS        0000000000000000 00303b 000030 00      0   0  1
  [29] .debug_info       PROGBITS        0000000000000000 00306b 000472 00      0   0  1
  [30] .debug_abbrev     PROGBITS        0000000000000000 0034dd 000184 00      0   0  1
  [31] .debug_line       PROGBITS        0000000000000000 003661 00017e 00      0   0  1
  [32] .debug_str        PROGBITS        0000000000000000 0037df 00031a 01  MS  0   0  1
  [33] .debug_line_str   PROGBITS        0000000000000000 003af9 00012f 01  MS  0   0  1
  [34] .symtab           SYMTAB          0000000000000000 003c28 000438 18     35  18  8
  [35] .strtab           STRTAB          0000000000000000 004060 00028c 00      0   0  1
  [36] .shstrtab         STRTAB          0000000000000000 0042ec 00016a 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)

The main topic of this tutorial is the sections. So I wanna explain in deeply each one:

.init and .fini: The machine code in these sections are used before/after the main() function in program. Don't forget that we're not writing this sections. Compiler itself creates these to handle low-level (or hardware-specific) works. I don't know actually what both of them do!
.text: It is the main area where we focus on binary analysis and reverse-engineering stuffs and includes the your code in machine instruction representation. If you look at there, you see that it has voluminous area and thousands of lines of machine code even if it is small program.
.bss, .data and .rodata: These sections are writable and used to hold various variable in source code. .bss includes the static and global uninitialized and .data includes the static and global initialized variables. Also .rodata consists of variables defined with const keyword in code.
.dynamic: This is the "road map" for the kernel and dynamic linker when loading and setting up an ELF binary for executions.
.init_array and .fini_array: These contains an array of pointers to functions to use as constructors/destructors. You maybe know that how to create constructor and destructor using compiler specific-tool, line one __attribute__((constructor)) void run_before_main(void);.
.shstrtab, .symtab, .strtab, .dynsym and .dynstr: The .shstrtab section is simply an array of NULL-terminated strings that contain the names of all the sections in binary. The .symtab contains a symbol table and .strtab contains the symbolic names. The .dynsym and .dynstr are analogous to .symtab and .strtab, except that they contain symbols and strings needed for dynamic linking rather than static linking.
.debug_: These sections are used primarily by debugger (GDB) so that it has not include and machine code but just metadata about program that debugger can use later. If you don't compile the program with -g option, these sections will not there.

Below is a part of .text section:

$ objdump -j .text -d ./copy

./copy:     file format elf64-x86-64

(...)

Disassembly of section .text:

0000000000001249 <main>:
    1249:f3 0f 1e fa          endbr64
    124d:55                   push   %rbp
    124e:48 89 e5             mov    %rsp,%rbp
    1251:48 81 ec 40 04 00 00 sub    $0x440,%rsp
    1258:89 bd cc fb ff ff    mov    %edi,-0x434(%rbp)
    125e:48 89 b5 c0 fb ff ff mov    %rsi,-0x440(%rbp)
    1265:64 48 8b 04 25 28 00 mov    %fs:0x28,%rax
    126c:00 00 
    126e:48 89 45 f8          mov    %rax,-0x8(%rbp)
    1272:31 c0                xor    %eax,%eax
    1274:83 bd cc fb ff ff 03 cmpl   $0x3,-0x434(%rbp)
    127b:75 24                jne    12a1 <main+0x58>
    127d:48 8b 85 c0 fb ff ff mov    -0x440(%rbp),%rax
    1284:48 83 c0 08          add    $0x8,%rax
    1288:48 8b 00             mov    (%rax),%rax
    128b:48 8d 15 72 0d 00 00 lea    0xd72(%rip),%rdx        # 2004 <_IO_stdin_used+0x4>

(...)

In here, we see the three columns that show the machine instructions of your program. At left side, you see the addresses of machine instructions. When running the program, stack pointer tracks these addresses. At center, you see the actual machine instructions corresponding to your code. Program counter register tracks this machine instructions. At right side, you see the assembly-level representations. When dealing with reverse-engineering, we inspect these to understand what program does.

Virtual Memory Layout

After discussed the ELF program format, right now, I will explain the virtual memory layout of a process (running program instance). When you run the program, kernel creates a memory layout as below:

I've explained the .text, .data, .bss, and .rodata sections previously. Apart from these, you see the stack and heap areas.

Both are the memory areas that kernel uses to execute the machine instructions. Stack area has LIFO (Last-In First-Out) model. When executing the program, kernel pushes/pops the instructions in here. So it grows up to lower address space. Heap area is completely different! It has FIFO (First-In First-Out) model. Kernel uses this memory space for dynamic allocation with malloc()/free() function family. And it grows up to upper address space. The heap address border is claimed by brk() function.

Until here, I wanna give you a general overview about programs and processes. If you want to dive in more, you can check and look at the below references.

[1]. Kerrisk M., The Linux Programming Interface, no starch press, San Francisco, page 113.
[2]. Andriesse D., Practical Binary Analysis, no starch press, San Francisco, page 33.

Safe and Secure Software - MISRA C:2012

Can Gulmez — Tue, 11 Nov 2025 14:51:31 +0000

We say that programming languages like C, C++, Rust as "general-purpose". That means that we can do everything (theoretically) with these. But in critical system development (let's say military or aerospace), we need some rules to use the languages safely and securely.

In this article, I'm gonna explain the MISRA C:2012 rules and example code blocks. Let's start!

Note: I'm gonna dive into the important rules in later posts.

A standard C environment

Rule 1.1: The program shall contain no violations of the standard C syntax and constraints, and shall not exceed the implementation's translation limits.

Rule 1.2: Language extensions should not be used.

void outer(void)
{
    printf("Outer function!\n");

    __extension__ void inner(void)  /* VIOLATION */
    {
        printf("Inner function!\n");
    }
    inner();
}

Rule 1.3: There shall be no occurrence of undefined or critical unspecified behaviour.

Unused code

Rule 2.1: A project shall not contain unreachable code.

void main(int argc, char *argv[])
{
    int res;

    exit(EXIT_SUCCESS);

    res = 1;        /* VIOLATION */
}

Rule 2.2: There shall be no dead code.
Rule 2.3/4/5: A project should not contain unused type/tag/macro declarations.

int func(void)
{
#define DATA    5
#define SIZE    10      /* VIOLATION */

    return DATA;
}

Rule 2.6: A function should not contain unused label declarations.
Rule 2.7: There should be no unused parameters in functions.

Comments

Rule 3.1: The character sequences /* and // shall not be used within a comment.
Rule 3.2: Line-splicing shall not be used in // comments.

Character sets and lexical conventions

Rule 4.1: Octal and hexadecimal escape sequences shall not be terminated.
Rule 4.2: Trigraphs should not be used.

Identifiers

Rule 5.1: External identifiers shall be distinct.
Rule 5.2: Identifiers declared in the same scope and name space shall be distinct.
Rule 5.3: An identifier in an inner scope shall not hide an identifier declared in an outer scope.

int func(void)
{
    int i;
    {
        int i;  /* VIOLATION */

        i = 4;
    }
}

Rule 5.4: Macro identifiers shall be distinct.
Rule 5.5: Identifiers shall be distinct from macro names.
Rule 5.6/7: A typedef/tag name shall be a unique identifier.
Rule 5.8/9: Identifiers that define objects or functions with external/internal linkage shall be unique.

Types

Rule 6.1: Bit-fields shall only be declared with an appropriate type.

struct s {
    unsigned int a:2;   
    int          b:2; /* VIOLATION (plain int not permitted) */
};

Rule 6.2: Single-bit named bit fields shall not be of a signed type.

Literals and constants

Rule 7.1: Octal constants shall not be used.
Rule 7.2: A "u" or "U" suffix shall be applied to all integer constants that are represented in an unsigned type.
Rule 7.3: The lowercase character "l" shall not be used in a literal suffix.

const int64_t   a = 0L;
const int64_t   b = 0l;     /* VIOLATION */
const uint64_t c = 0Lu; 
const uint64_t d = 0lU;     /* VIOLATION */

Rule 7.4: A string literal shall not be assigned to an object unless the object's type is "pointer to const-qualified char".

const volatile char *s1 = "string";
char *s2 = "string";                            /* VIOLATION */

Declarations and definations

Rule 8.1: Types shall be explicitly specified.

extern          x;      /* VIOLATION (implicit int type) */
extern int16_t y;
const           z;      /* VIOLATION (implicit int type) */
extern int32_t q;

Rule 8.2: Function types shall be in prototype form with named parameters.
Rule 8.3: All declarations of an object or function shall use the same names and type qualifiers.

extern f(signed int param);
         f(int param);              /* Okey */
extern g(int * const param);
         g(int * p);                /* VIOLATION */

Rule 8.4: A compatible declaration shall be visible when an object or function with external linkage is defined.

extern int x;
         int x = 5;     /* OK */

int y = 3;              /* VIOLATION - no prior declaration */

Rule 8.5: An external object or function shall be declared once in one or only one file.
Rule 8.6: An identifier with external linkage shall have exactly one external definition.
Rule 8.7: Functions and objects should not be defined with external linkage if they are referenced in only one translation unit.
Rule 8.8: The static storage class specifier shall be used in all declarations of objects and functions that have internal linkage.

static int32_t x = 0;
extern int32_t x;     /* VIOLATION */

Rule 8.9: An object should be defined at block scope if its identifier only appears in a single function.
Rule 8.10: An inline function shall be declared with the static storage class.
Rule 8.11: When an array with external linkage is declared, its size should be explicitly specified.
Rule 8.12: Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique.
Rule 8.13: A pointer should point to a const-qualified type whether possible.
Rule 8.14: The restrict type qualifier shall not be used.

Initialization

Rule 9.1: The value of an object with automatic storage duration shall not be read before it has been set.

void f(bool_t b, uint16_t *p)
{
    if (b) {
        *p = 3U;
    }
}

void g(void)
{
    uint16_t u;

    f(false, &u);

    if (u == 3U) {
        /* VIOLATION - u has not be assigned a value */
    }
}

Rule 9.2: The initializer for an aggregate or union shall be enclosed in braces.
Rule 9.3: Arrays shall not be partially initialized.
Rule 9.4: An element of an object shall not be initialized more than once.
Rule 9.5: Where designated initializers are used to initialize an array object, the size of the array shall be specified explicitly.

int a1[5] = {0};            /* OK */
int a2[] = {4, 7, 1};   /* VIOLATION */

The essential type model

Rule 10.1: Operands shall not be of an inappropriate essential type. (I did not understand that yet 😂, look at page 82-84 at MISRA C:2012 Guidelines).
Rule 10.2: Expressions of essential character type shall not be used inappropriately in addition and subtraction operations.
Rule 10.3: The value of an expression shall not be assigned to an object with a narrower essential type or of a different essential type category.
Rule 10.4: Both operands of an operator in which the usual arithmetic conversions, are performed shall have the same essential type category.
Rule 10.5: The value of an expression should not be cast to an inappropriate essential type.
Rule 10.6: The value of a composite expression shall not be assigned to an object with wider essential type.
Rule 10.7: If a composite expression is used as one operand of an operator in which the usual arithmetic conversions are performed then the other operand shall not have wider essential type.
Rule 10.8: The value of a composite expression shall not be cast to a different essential type category or a wider essential type.

Pointer type conversions

Rule 11.1: Conversions shall not be performed between a pointer to function and any other type.

typedef void (*fp16) (int16_t n);
typedef void (*fp32) (int32_t n);

fp16 fp1 = NULL;                /* OK */
fp32 fp2 = (fp32) fp1;      /* VIOLATION - a function pointer to different one */

if (fp2 != NULL) {          /* OK */

}

fp16 fp3 = (fp16) 0x8000;   /* VIOLATION - integer into function pointer */

Rule 11.2: Conversions shall not be performed between a pointer to an incomplete type and any other type.

struct s;
struct t;
struct s *sp;
struct t *tp;
int16_t *ip;

sp = NULL;                      /* OK */
ip = (int16_t *) sp;            /* VIOLATION */
sp = (struct s *) 1234;     /* VIOLATION */
tp = (struct t *) sp;       /* VIOLATION */

Rule 11.3: A cast shall not be performed between a pointer to object type and a pointer to a different object type.

uint8_t *p1;
uint32_t *p2;

p2 = (uint32_t *) p1;           /* VIOLATION */

const short *p;
const volatile short *q;

q = (const volatile short *) p; /* OK */

Rule 11.4: A conversion should not be performed between a pointer to object and an integer type.

uint16_t *p;

int32_t addr = (int32_t) &p;        /* VOILATION */
uint8_t *q = (uint_t *) addr;       /* VIOLATION */
bool_t b = (bool_t) p;              /* VIOLATION */

enum tag {A, B, C};

enum tag e = (enum tag) p;          /* VIOLATION */

Rule 11.5: A conversion should not be performed from pointer to void into pointer to object (except NULL).

uint32_t *p32;
void *p;
uint16_t *p16;

p = p32;                    /* OK */
p16 = p;                    /* VIOLATION */
p = (void*) p16;        /* OK */
p32 = (uint32_t *);     /* VIOLATION */

Rule 11.6: A cast shall not be performed between pointer to void and an arithmetic type.

void *p;
uint32_t u;

p = (void *) 0x1234u;   /* VIOLATION */
u = (uint32_t) p;           /* VIOLATION */

Rule 11.7: A cast shall be performed between pointer to object and a non-integer arithmetic type.

int16_t *p;
float32_t f;

f = (float32_t) p;  /* VIOLATION */
p = (int16_t *) f;  /* VIOLATION */

Rule 11.8: A cast shall not remove const or volatile qualification from the type pointed to by a pointer.
Rule 11.9: The macro NULL shall be the only permitted form of integer null pointer constant.

int32_t *p1 = 0;                /* VIOLATION */
int32_t *p2 = (void *) 0;   /* OK */

Expressions

Rule 12.1: The precedence of operators within expressions should be made explicit.
Rule 12.2: The right hand operand of a shift operator shall lie in the range zero to one less than the width in bits of the essential type of the left hand operand.
Rule 12.3: The comma operator should not be used.
Rule 12.4: Evaluation of constant expressions should not lead to unsigned integer wrap-around.

#define DELAY       10000u
#define WIDTH       60000u

void fixed_pulse(void)
{
    uint16_t off_time16 = DELAY + WIDTH;    /* VIOLATION */
}

Side effects

Rule 13.1: Initializer lists shall not contain persistent side effects.

volatile uint16_t v1;

void f(void)
{
    uint16_t a[2] = {v1, 0};    /* VIOLATION - volatile is side effect */
}

void g(uint16_t x, uint16_t y)
{
    uint16_t a[2] = {x + y, x - y}; /* OK */
}

Rule 13.2: The value of an expression and its persistent side effects shall be the same under all permitted evaluation orders.
Rule 13.3: A full expression containing an increment (++) or decrement (--) operator should have no other potential side effects other than that caused by the increment or decrement operator.

u8a = u8b++;                /* VIOLATION */
u8a = ++u8b + u8c--;        /* VIOLATION */
x++;                            /* OKEY */
a[i]++;                     /* OK */
c->x++;                     /* OK */
*p++;                           /* OKEY */
(*p)++;                     /* OK */
++(*p);                     /* OK */

Rule 13.4: The result of an assignment operator should not be used.

x = y;              /* OK */
a[x] = a[x = y];    /* VIOLATION */

Rule 13.5: The right hand operand of a logical && or || operator shall not contain persistent side effects.
Rule 13.6: The operand of the sizeof operand shall not contain any expression which has potential side effects.

Control statement expressions

Rule 14.1: A loop counter shall not have essential floating type.
Rule 14.2: A for loop shall be well-formed.
Rule 14.3: Controlling expressions shall not be invariant.
Rule 14.4: The controlling expression of an if statement and the controlling expression of an iteration-statement shall have essential Boolean type.

int32_t *p, *q;

while (p)               /* VIOLATION */
{
}

while (q != NULL)       /* OK */
{
}

while (true)            /* OK */
{
}

Control flow

Rule 15.1: The goto statement should not be used.
Rule 15.2: The goto statement shall jump to a label declared later in the same function.
Rule 15.3: Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement.
Rule 15.4: There should be no more than one break or goto statement used to terminate any iteration statement.
Rule 15.5: A function should have a single point of exit at the end.
Rule 15.6: The body of an iteration-statement or a selection-statement shall be a compound-statement.

while (true)            /* VIOLATION */
    process_data();

while (true)            /* OK */
{
    process_data();
}

Rule 15.7: All if ... else if constructs shall be terminated with an else statement.

Switch statements

Rule 16.1: All switch statements shall be well-formed.
Rule 16.2: A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement.
Rule 16.3: An unconditional break statement shall terminate every switch-clause.

switch (x)
{
    case 0:         /* OK */
        break;  
    case 1:         /* OK */
    case 2:         /* OK */
        break;
    case 4:         /* VIOLATION */
        a = b;
    default:            /* VIOLATION - 'default' even should have 'break' */
        ;
}

Rule 16.4: Every switch statement shall have a default label.
Rule 16.5: A default label shall appear as either the first or the last switch label of a switch statement.
Rule 16.6: Every switch statement shall have at least two switch-clauses.
Rule 16.7: A switch-expression shall not have essential Boolean type.

Functions

Rule 17.1: The features of <stdarg.h> shall not be used.
Rule 17.2: Functions shall not call themselves, either directly or indirectly.
Rule 17.3: A function shall not be declared implicitly.
Rule 17.4: All exit paths from a function with non-void return type shall have an explicit return statement with an expression.
Rule 17.5: The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements.
Rule 17.6: The declaration of an array parameter shall not contain static keyword between the [].
Rule 17.7: The value returned by a function having non-void return type shall be used.
Rule 17.8: A function parameter should not be modified.

Pointers and arrays

Rule 18.1: A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand.

void f(void)
{
    int32_t data = 0;
    int32_t b = 0;
    int32_t c[10] = {0};
    int32_t d[5][2] = {0};

    int32_t *p1 = &c[0];        /* OK */
    int32_t *p2 = &c[10];   /* OK (even) */
    int32_t *p3 = &c[11];   /* VIOLATION */

    data = *p2;                 /* VIOLATION */

    p1++;                           /*  OK */
    c[-1] = 0;                  /* VIOLATION */
}

Rule 18.2: Subtraction between pointers shall only be applied to pointers that address elements of the same array.

void f(void)
{
    int32_t a1[10];
    int32_t a2[10];
    int32_t *p1 = &a1[1];
    int32_t *p2 = &a2[10];
    ptrdiff_t diff;

    diff = p1 - a1;     /* OK */
    diff = p2 - a2;     /* OK */
    diff = p1 - p2;     /* VIOLATION */
}

Rule 18.3: The relational operators >, >=, < and <= shall not be applied to objects of pointer type except where they point into the same object.
Rule 18.4: The +, -, +=, -= operators should not be applied to an expression of pointer type.
Rule 18.5: Declarations should contain no more than two levels of pointer nesting.
Rule 18.6: The address of an object with automatic storage shall not be copied to another object that persists after the first object has ceased to exist.

int8_t *f(void)
{
    int8_t local;

    return &local;      /* VIOLATION */
}

uint16_t *sp;

void g(uint16_t *p)
{
    sp = p;             /* VIOLATION */
}

Rule 18.7: Flexible array members shall not be declared.
Rule 18.8: Variable-length array types shall not be used.

Overlapping storage

Rule 19.1: An object shall not be assigned or copied to an overlapping object.

void f(void)
{
    union {
        int16_t i;
        int16_t j;
    } a = {0}, b = {1};

    a.j = a.i;      /* VIOLATION */
}

Rule 19.2: The union keyword should not be used.

Preprocessing directives

Rule 20.1: #include directives should only be preceded by preprocessor directives or comments.
Rule 20.2: The ', " or \ characters and the /* or // character sequences shall not occur in a header file name.
Rule 20.3: The #include directive shall be followed by either a <filename> or "filename" sequence.
Rule 20.4: A macro shall not be defined with the same name as a keyword.
Rule 20.5: #undef should not be used.
Rule 20.6: Tokens that look like a preprocessing directive shall not occur with a macro argument.
Rule 20.7: Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses.
Rule 20.8: The controlling expression of a #if or #elif preprocessing directive shall evaluate to 0 or 1.
Rule 20.9: All identifiers used in the controlling expression of #if or #elif preprocessing directives shall be #define'd before evaluation.
Rule 20.10: The # and ## preprocessor operators should not be used.
Rule 20.11: A macro parameter immediately following a # operator shall not immediately be followed by a ## operator.

#define A(x)        #x      /* OK */
#define B(x, y) x ## y  /* OK */
#define C(x, y)   #x ## y   /* VIOLATION */

Rule 20.12: A macro parameter used as an operand to the # or ## operators, which is itself subject to further macro replacement, shall only be used as an operand to these operators.
Rule 20.13: A line whose first token is # shall be a valid preprocessing directive.
Rule 20.14: All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if, #ifdef or #ifndef directive to which they are related.

Standard libraries

Rule 21.1: #define and #undef shall not be used on a reserved identifier or reserved macro name.

#undef __LINE__                 /* VIOLATION (begins with _) */
#define _GUARD_H    1               /* VIOLATION (begins with _) */

#define defined                 /* VIOLATION (reserved identifier) */
#define errno my errno          /* VIOLATION (library identifier) */
#define isneg(x)    ((x) < 0)   /* OKEY */

Rule 21.2: A reserved identifier or macro name shall not be declared.
Rule 21.3: The memory allocation and deallocation functions of <stdlib.h> shall not be used.
Rule 21.4: The standard header file <setjmp.h> shall not be used.
Rule 21.5: The standard header file <signal.h> shall not be used.
Rule 21.6: The standard library input/output functions shall not be used.
Rule 21.7: The atof, atol, atoll functions of <stdlib.h> shall not be used.
Rule 21.8: The library functions abort, exit, getenv and system of <stdlib.h> shall not be used.
Rule 21.9: The library functions bsearch and qsort of <stdlib.h> shall not be used.
Rule 21.10: The standard library time and date functions shall not be used.
Rule 21.11: The standard header file <tgmath.h> shall not be used.
Rule 21.12: The exception handling features of <fenv.h> should not be used.

Resources

Rule 22.1: All resources obtained dynamically by means of standard library functions shall be explicitly released.

int f(void)
{
    void *a = malloc(40);

    /* VIOLATION - not released */
    return 1;
}

int g(void)
{
    FILE *fp = fopen("file", "r");

    /* VIOLATION - not closed */
    return 1;
}

Rule 22.2: A block of memory shall only be freed if it was allocated by means of a standard library function.
Rule 22.3: The same file shall not be open for read and write access at the same time on different streams.
Rule 22.4: There shall no attempt to write to a stream which has been opened as read-only.
Rule 22.5: A pointer to a FILE object shall not be dereferenced.
Rule 22.6: The value of a pointer to a FILE shall not be used after the associated stream has been closed.

Interrupt Management in ARM Cortex-M

Can Gulmez — Sat, 18 Oct 2025 17:46:52 +0000

Interrupts is the must-known concept in embedded programming. So I wanna explain the interrupt management in ARM Cortex-M.

ARM architecture distinguishes between the two types: interrupt and system exception. Interrupts are primarily sourced by external hardware like UART that warns about arrival of data. System exceptions are more software-related and caused by ARM Cortex internal.

Interrupts and system exceptions are exchangeably used. But even if both of these do same thing (especially in programming), the differences are important for us, engineers!

I'll use "interrupt" word for both terms further, if otherwise declared.

Before diving into interrupts, you need to understand the general execution workflow of ARM Cortex. There are two types of execution modes: thread and interrupt. After resetting the microcontroller, execution flow starts in thread mode so that if you want to use interrupts, you need to enter the interrupt mode. But how?

When you flash your firmware into microcontroller (base address of 0x08000000, in case), ARM Cortex starts to execute the firmware's machine instructions in thread mode. If you want to use any interrupt, you have to explicitly say it to ARM Cortex by using Interrupt Service Routines (ISRs). ISRs are actually standard C functions, but have the special signatures. I'm gonna explain it later.

The most important question about interrupts is that why do we need interrupts?

The answer: Interrupts are the source of multiprogramming!

Interrupts give us second execution flow besides the main flow (executed in thread mode by default). It also gives the context switch mechanism for RTOS. I will explain it lastly.

ARM Cortex has a special hardware called Nested Vectored Interrupt Controller (NVIC). It handles and manages the all interrupt usage. Below is the its simple schematic:

Another important dedicated hardware is the EXTI Controller. The peripheral interrupts in the microcontroller directly are connected to NVIC. But If you want to use interrupts over microcontroller pins (like detecting rising or falling edge of a button), you have to use EXTI lines. Microcontroller pins are grouped and tied to specific EXTI lines. Please look at the reference manual to find it.

We have many different types of interrupts. For now, let's look at these:

ARM Cortex has defined 15 fixed system exceptions (coming from internal of Cortex). But microcontroller vendors specify also variable-length interrupts (coming from external of Cortex). For example, STM32 series microcontrollers allow up to 256 interrupts.

But where are located these interrupts? The answer is the at vector table.

The vector table is an array of word data inside the system
memory, each representing the starting address of one exception type [1].

If you've flashed any firmware into microcontroller over OpenOCD + GDB, you've seen probably the this vector table. If you've not, let's see it exactly.

I have STM32F446RE microcontroller and ST-LINK connection. I've compiled a firmware (firmware.elf) to flash it. Open a terminal and type:

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

And open the second terminal and type:

$ arm-none-eabi-gdb firmware.elf

Lastly, type these into GDB session:

(gdb) target remote localhost:3333
(gdb) monitor reset halt
(gdb) load

After flashed the firmware into microcontroller, you will see:

Loading section .isr_vector, size 0x1c4 lma 0x8000000
Loading section .text, size 0x1080 lma 0x80001d0
Loading section .rodata, size 0x10 lma 0x8001250
Loading section .init_array, size 0x4 lma 0x8001260
Loading section .fini_array, size 0x4 lma 0x8001264
Loading section .data, size 0x10 lma 0x8001268
Start address 0x80011d0, load size 4716
Transfer rate: 9 KB/sec, 786 bytes/write.

Yeah! You see the interrupt vector table (.isr_vector) section was flashed at the base address of flash memory and other sections after the vector table. If you use any type of interrupt, the ARM Cortex gets the corresponding ISR handler from there so that ARM Cortex exactly knows the ISR handler addresses. You just need to select the required ISR handler function!

As I said before, ISR handlers are special type of C functions. But why? Because the handlers have predefined function prototypes. You have to use these function prototypes. Otherwise, ARM Cortex cannot find it and treated as normal C functions, not the ISR handlers.

These predefined handler prototypes are stored in the startup code. For STM32F446RE, it is startup_stm32f446xx.S file. Below is a part of this startup code:

(...)

  .word  Reset_Handler
  .word  NMI_Handler
  .word  HardFault_Handler
  .word  MemManage_Handler
  .word  BusFault_Handler

(...)

  .word     CAN1_TX_IRQHandler                /* CAN1 TX                      */                         
  .word     CAN1_RX0_IRQHandler               /* CAN1 RX0                     */                          
  .word     CAN1_RX1_IRQHandler               /* CAN1 RX1                     */                          
  .word     CAN1_SCE_IRQHandler               /* CAN1 SCE                     */                          
  .word     EXTI9_5_IRQHandler                /* External Line[9:5]s          */                          
  .word     TIM1_BRK_TIM9_IRQHandler          /* TIM1 Break and TIM9          */         
  .word     TIM1_UP_TIM10_IRQHandler          /* TIM1 Update and TIM10        */         
  .word     TIM1_TRG_COM_TIM11_IRQHandler     /* TIM1 Trigger and Commutation and TIM11 */
  .word     TIM1_CC_IRQHandler                /* TIM1 Capture Compare         */                          
  .word     TIM2_IRQHandler                   /* TIM2                         */                   
  .word     TIM3_IRQHandler                   /* TIM3                         */                   
  .word     TIM4_IRQHandler                   /* TIM4                         */                   
  .word     I2C1_EV_IRQHandler                /* I2C1 Event                   */                          
  .word     I2C1_ER_IRQHandler                /* I2C1 Error                   */                          
  .word     I2C2_EV_IRQHandler                /* I2C2 Event                   */                          
  .word     I2C2_ER_IRQHandler                /* I2C2 Error                   */          

(...)

At the beginning, I've stated that interrupts are the source of multiprogramming. This is core logic behind the RTOS!

RTOSes use the interrupts to create many tasks. In classic firmware written with RTOS, there are many tasks that the RTOS kernel have to handle and manage. You can think that task in the firmware corresponds to process in the computers.

The RTOS kernel needs to execute these tasks in order and with same time-slice so that the kernel cuts the one task execution and passes to the next task execution using context switches. This is done by using interrupts. For example, FreeRTOS kernel uses SVC and PendSV interrupts specificly to make the contex switch. Apart from that, the RTOS kernel uses also the SysTick interrupt to give the equal execution time to each task.

Got it. I've explain the interrupt management in ARM Cortex-M in general. I put the some references below. You can look at the interrupts and similar topics in there.

References:

[1]. Yiu J., The Definitive Guide to The ARM Cortex-M3, Second Edition, Newnes, page 36.

Noviello C., Mastering STM32, 0.26 Release, Leanpub

How to write HAL (Hardware Abstraction Layer) Library for MCUs?

Can Gulmez — Thu, 16 Oct 2025 10:44:38 +0000

In embedded programming, we use mostly libraries, IDEs, extensions or so on. I'm on that way also. This gives us the simplicity and consistency. But even we should do that at projects, I think that every embedded programmer should now what is going on under the hood!

In this post, I wanna share how to write a minimal HAL library (just for LED blinking) for STM32F446RE microcontroller. I just will do simple memory mappings and register operations so that it will be simple, but you will learn the most important stuffs about embedded programming.

Firstly, you have to know exactly two terms: memory mapping and register operations. So embedded programming (nearly) is all about these.

Every microcontroller has a memory layout and this layout is separated into different groups. We know that which address owns what. For example, if I wanna use GPIO peripheral, I should look at memory address of that GPIO from the microcontroller's reference manual.

In STM32F4 series microcontrollers, 0x40000000 is the base address for all peripherals. Below is a part of peripherals' memory layout:

We see the what type of peripheral lays out at which addresses and busses. So we use these addresses when programming embedded device.

Don't forget that I will just write a minimal library that just can blink the LED. But the logic behind it is persistent for other applications.

What exactly is there at the peripheral addresses? The question is registers. Every peripheral has a set of registers that make the peripheral usable. Registers are the main topic in embedded world so that you have to know what is exactly it and how works?

A register is a 32-bit addressed data holder at all and used to do a "work". Every register in a peripheral has a special work and all registers make the peripheral active. We set the bits of these registers so that it is programmed!

Embedded programming is all about the setting up the bits of registers.

So that beside the memory mapping, registers must also be defined in the source code. Below is RCC AHB1 peripheral clock enable register as an example (we'll use this to enable the clock of GPIOA port further):

After giving the core logic behind the embedded programming, let's start writing library. You can use any IDE/extension for compiling, flashing and debugging. I'm gonna use PlatformIO extension within VS Code. I've created main.h and main.c source files. In main.h, I'm gonna define the memory mappings and registers and, in main.c, I will blink the LED. Let's start!

According to reference manual (look at "2.2. Memory organization"):

#define APB1_BASEADDR               0x40000000UL
#define APB2_BASEADDR               0x40010000UL
#define AHB1_BASEADDR               0x40020000UL
#define AHB2_BASEADDR               0x50000000UL
#define AHB3_BASEADDR               0xA0001000UL

#define GPIOA_BASEADDR              (AHB1_BASEADDR + 0x0UL)
#define RCC_BASEADDR                (AHB1_BASEADDR + 0x00003800UL)

We've defined the bus and GPIO port addresses. As I said before, I just write for LED blinking (connected to PA0 pin of microcontroller) so that we just need the GPIO and RCC peripherals.

By the way, RCC (Reset and Clock Control) is peripheral that is used to reset/clock the microcontroller peripherals. I need to enable the clock of GPIOA port firstly.

After the defined memory mappings, let's define the peripheral registers. As I said before, we have many registers that belong to its peripheral. It is good practice to use struct:

typedef unsigned int uint32_t;

typedef struct {
    volatile uint32_t CR;           /* RCC clock control */
    volatile uint32_t PLLCFGR;      /* RCC PLL configuration */
    volatile uint32_t CFGR;         /* RCC clock configuration */
    volatile uint32_t CIR;          /* RCC clock interrupt */
    volatile uint32_t AHB1RSTR; /* RCC AHB1 peripheral reset */
    volatile uint32_t AHB2RSTR; /* RCC AHB2 peripheral reset */
    volatile uint32_t AHB3RSTR; /* RCC AHB3 peripheral reset */
    volatile uint32_t NA1;          /* Reversed */
    volatile uint32_t APB1RSTR; /* RCC APB1 peripheral reset */
    volatile uint32_t APB2RSTR; /* RCC APB2 peripheral reset */
    volatile uint32_t NA2;          /* Reversed */
    volatile uint32_t NA3;          /* Reversed */
    volatile uint32_t AHB1ENR;      /* RCC AHB1 peripheral clock enable */
    volatile uint32_t AHB2ENR;      /* RCC AHB2 peripheral clock enable */
    volatile uint32_t AHB3ENR;      /* RCC AHB3 peripheral clock enable */
    volatile uint32_t NA4;          /* Reversed */
    volatile uint32_t APB1ENR;      /* RCC APB1 peripheral clock enable */
    volatile uint32_t APB2ENR;      /* RCC APB2 peripheral clock enable */
    volatile uint32_t NA5;          /* Reversed */
    volatile uint32_t NA6;          /* Reversed */
    volatile uint32_t AHB1LPENR;    /* RCC AHB1 peripheral clock enable in low power mode */
    volatile uint32_t AHB2LPENR;    /* RCC AHB2 peripheral clock enable in low power mode */
    volatile uint32_t AHB3LPENR;    /* RCC AHB3 peripheral clock enable in low power mode */
    volatile uint32_t NA7;          /* Reversed */
    volatile uint32_t APB1LPENR;    /* RCC APB1 peripheral clock enable in low power mode */
    volatile uint32_t APB2LPENR;    /* RCC APB2 peripheral clock enable in low power mode */
    volatile uint32_t NA8;          /* Reserved */
    volatile uint32_t NA9;          /* Reserved */
    volatile uint32_t BDCR;         /* RCC backup domain control */
    volatile uint32_t CSR;          /* RCC clock control & status */
    volatile uint32_t NA10;         /* Reserved */
    volatile uint32_t NA11;         /* Reserved */
    volatile uint32_t SSCGR;        /* RCC spread spectrum clock generation */
    volatile uint32_t PLLI2SCFGR;   /* RCC PLLI2S configuration */
    volatile uint32_t PLLSAICFGR;   /* RCC PLL configuration */
    volatile uint32_t DCKCFGR;      /* RCC dedicated clock configuration */
    volatile uint32_t CKGATENR; /* RCC clocks gated enable */
    volatile uint32_t DCKCFGR2; /* RCC dedicated clocks configuration 2 */
} RCC_Handler;

typedef struct {
    volatile uint32_t MODER;        /* GPIO port mode */
    volatile uint32_t OTYPER;       /* GPIO port output type */
    volatile uint32_t OSPEEDR;      /* GPIO port output speed */
    volatile uint32_t PUPDR;        /* GPIO port pull-up/pull-down */
    volatile uint32_t IDR;          /* GPIO port input data */
    volatile uint32_t ODR;          /* GPIO port output data */
    volatile uint32_t BSRR;         /* GPIO port bit set/reset */
    volatile uint32_t LCKR;         /* GPIO port configuration lock */
    volatile uint32_t AFRL;         /* GPIO alternate function low */
    volatile uint32_t AFRH;         /* GPIO alternate function high */
} GPIO_Handler;

#define RCC                          ((RCC_Handler *) RCC_BASEADDR)
#define GPIOA                           ((GPIO_Handler *) GPIOA_BASEADDR)

Please recheck your reference manual and define the correct registers (look at "6.3. RCC Registers" and "7.4. GPIO Registers").

Don't forget that each peripheral register has 32-bit length. Also defining the registers with volatile keyword is good practice. This tells to compiler: "Hey compiler, you don't have to optimize register variables because they will probably be changed quickly".

Another point is that you have to follow the register offsets. For example, MODER register of GPIOA port is at 0x40020000 so the next register, OTYPER, address should be at 0x40020004 (32-bit offset). Generally, registers are queued so that you just put these in struct in order. But sometimes, there can be offset gaps, as being in RCC registers. If you look at carefully at RCC_Handler, there are NAx (Not Applicable) variables. These are not registers. It's the placeholders. Because of at that offset, any register is not defined.

Right now, let's define the main() (entry-point) like this:

void main(void)
{
    RCC->AHB1ENR |= (1 << 0);       /* Enable GPIOA clock */

    GPIOA->MODER |= (1 << 0);       /* General purpose output mode */
    GPIOA->OTYPER &= ~(1 << 0); /* Output push-pull */
    GPIOA->OSPEEDR &= ~(3 << 0);    /* Low speed */
    GPIOA->PUPDR &= ~(3 << 0);; /* No pull-up, pull-down */
    GPIOA->BSRR = (1 << 0);         /* Set (1 << 16 for reset) */

    while (1);
}

In here, we used the bitwise operations to manipulate the register bits. I assume that you already know it from your programming background.

What exactly bits are manipulated?

1. bit of RCC AHB1 register
1. and 2. bits of GPIO MODER register
1. bit of GPIO OTYPER register
1. and 2. bits of GPIO OSPEEDR register
1. and 2. bits of GPIO PUPDR register
1. bit of GPIO BSRR register

Finally, you can compile and then flash this program to the microcontroller. That's it 🥳🥳🥳.

The Linux Programming Interface - Time

Can Gulmez — Wed, 15 Oct 2025 13:02:40 +0000

In any type of program, we mostly are interested in two different time:

Real (Calendar) time: This time is measured from a standard point (generally, UTC, 1 January 1970). Obtaining the calendar time is primarily source of what you see at screen of your computer.
Process time: This is the amount of CPU time used by a process. Measuring process time is useful for checking or optimizing the performance of a program or algorithm.

Every computer has a dedicated built-in hardware clock that enables the kernel to measure real and process time.

Calendar Time and Time Conversion

To handle real time, the GNU libraries give us many functions as below:

These are also function signatures that we use when handling time in the program:

time_t time(time_t *tloc);
char *asctime(const struct tm *tm);
char *ctime(const time_t *timep);
struct tm *gmtime(const time_t *timep);
struct tm *localtime(const time_t *timep);
time_t mktime(struct tm *tm);
size_t strftime(char *s, size_t max, const char *format, const struct tm *tm);

The time() system call returns the number of seconds since the Epoch (1 January 1970) and then this number of seconds are stored in time_t (typedef long time_t) data type.

To convert this number of seconds in printable format, we use the ctime() function.

We can also convert this number of seconds into a so-called broken-down time (struct tm) by using gmtime() and localtime() functions. After that, we see the year, month, week, hours and so on.

The mktime() function does vise-verse, translates a broken-down time into number of seconds.

We also use asctime() to convert broken-down time to printable format.

I put here a simple program that shows the how to use these functions I've described:

/* Retrieving and converting calendar times */

#include "../linux.h"

#define SECONDS_IN_TROPICAL_YEAR    (365.24219 * 24 * 60 * 60)

void main(int argc, char *argv[])
{
   time_t t;
   struct tm *gmp, *locp;
   struct tm gm, loc;
   struct timeval tv;

   t = time(NULL);
   printf("Seconds since the Epoch: %ld", (long) t);
   printf(" (about %6.3f years)\n", t / SECONDS_IN_TROPICAL_YEAR);

   if (gettimeofday(&tv, NULL) == -1)
      syscall_error();
   printf(" gettimeofday() returned %ld secs, %ld microsecs\n",
      (long) tv.tv_sec, (long) tv.tv_usec);

   gmp = gmtime(&t);
   if (gmp == NULL)
      syscall_error();

   gm = *gmp;  /* Save local copy */

   printf("Broken down by gmtime():\n");
   printf(" year=%d, mon=%d, mday=%d, hour=%d, min=%d, sec=%d ", 
      gm.tm_year, gm.tm_mon, gm.tm_mday, gm.tm_hour, gm.tm_min, gm.tm_sec);
   printf(" wday=%d, yday=%d, isdst=%d\n", gm.tm_wday, gm.tm_yday, gm.tm_isdst);

   locp = localtime(&t);
   if (locp == NULL)
      syscall_error();

   loc = *locp;   /* Save local copy */

   printf("Broken down by localtime():\n");
   printf(" year=%d, mon=%d, mday=%d, hour=%d, min=%d, sec=%d ", 
      loc.tm_year, loc.tm_mon, loc.tm_mday, loc.tm_hour, loc.tm_min, loc.tm_sec);
   printf(" wday=%d, yday=%d, isdst=%d\n", loc.tm_wday, loc.tm_yday, loc.tm_isdst);

   printf("asctime() formats the gmtime() value as: %s\n", asctime(&gm));
   printf("ctime() formats the time() value as: %s\n", ctime(&t));

   printf("mktime() of gmtime() value: %ld secs\n", (long) mktime(&gm));
   printf("mktime() of localtime() value: %ld secs\n", (long) mktime(&loc));

   exit(EXIT_SUCCESS);
}

The strftime() function provides us with more precise control when converting a broken-down into printable form. We just put pre-defined specifiers into third argument of strftime() function. These specifiers:

Below is the another program that shows the function usage:

/* A function that returns a string containing the current time */

#include "../linux.h"

#define BUF_SIZE  1000

/* Return a string containing the current time formatted according to
   the specification in 'format' (see strftime(3) for specifiers).
   If 'format' is NULL, we use "%c" as a specifier (which gives the
   date and time as for ctime(3), but without the trailing newline).
   Returns NULL on error. */

char *currTime(const char *format)
{
   static char buffer[BUF_SIZE];
   time_t t;
   size_t s;
   struct tm *tm;

   t = time(NULL);
   tm = localtime(&t); 
   if (tm == NULL)
      return NULL;

   s = strftime(buffer, BUF_SIZE, (format != NULL) ? format : "%c", tm);

   return (s == 0) ? NULL : buffer;
}

Timezones

Different countries operate on different timezones and DST regimes. Programs that input and output times must take care of this.

Timezone information tends to be both voluminous and volatile. So rather than encoding it directly into libraries, the system maintains this information in files under /usr/share/zoneinfo.

To specify a timezone when running a program, we set the TZ environment variable to a string consisting of a colon followed by one of the timezone names (like TZ=":Pacific/Auckland").

The tzset() function is used to obtain the current timezone setting. This function initializes three global variables:

char *tzname[2];
int daylight;
long timezone;

This function first checks the TZ environment variable. If this variable is not set, then the timezone is initialized to the default defined in the timezone file /etc/localtime. If the TZ environment variable is defined with a value that can't be matched to a timezone file, or it is an empty string, then UTC is used.

Locales

Different countries use different conventions for displaying information such as numbers, currency amounts, dates, and times.

Ideally, all programs designed to run in more than one location should deal with locales in order to display and input information in the user's preferred language and format. This constitutes the complex subject of internationalization (I18N).

Like timezone information, locales are maintained under /usr/share/locale. Under each locale subdirectory is a standard set of files that specify the conventions for this locale:

The setlocale() function is used to both set and query program's current locale. Below is the its function signature:

char *setlocale(int category, const char *locale);

There are two different methods of setting the locale. The locale argument may be a string specifying one of the locales defined under /usr/lib/locale or more conveniently selocale(LC_ALL, "") meaning that locale settings should be taken from environment variables.

Process Time

Process time is the amount of CPU time used by a process since it was created. For recording purposes, the kernel separates CPU time into the following two components:

User CPU time (amount of time spent executing in user mode)
System CPU time (amount of time spent executing in kernel mode)

Sometimes, we refer to process time as the total CPU time consumed by the process.

When dealing with process time, times() and clock() functions are used. Signatures are below:

clock_t times(struct tms *buf);
clock_t clock(void);

The times() system call retrieves process time information (both user and system time separately) and store it into struct tms.

Otherwise, clock() function is simpler and returns the total amount of CPU time. Below is the basic program that shows both of these functions.

/* Retrieving process CPU times */

#include "../linux.h"

void displayProcessTimes(const char *msg)
{
   struct tms t;
   clock_t clockTime;
   static long clockTicks = 0;

   if (msg != NULL)
      printf("%s", msg);

   if (clockTicks == 0) {  /* Fetch clock ticks on first call */
      clockTicks = sysconf(_SC_CLK_TCK);
      if (clockTicks == -1)
         syscall_error();
   }

   clockTime = clock();
   if (clockTime == -1)
      syscall_error();

   printf("clock() returns: %ld clocks-per-sec (%.2f secs)\n",
      (long) clockTime, (double) clockTime / CLOCKS_PER_SEC);

   if (times(&t) == -1)
      syscall_error();

   printf("times() yields: user CPU: %.2f; system CPU: %.2f\n", 
      (double) t.tms_utime / clockTicks, 
      (double) t.tms_stime / clockTicks);
}

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

   printf("CLOCKS_PER_SEC: %ld  sysconf(_SC_CLK_TCK): %ld\n\n",
      (long) CLOCKS_PER_SEC, sysconf(_SC_CLK_TCK));

   displayProcessTimes("At program start:\n");

   numCalls = (argc > 1) ? atoi(argv[1]) : 100000000;
   for (i = 0; i < numCalls; i++)
      (void) getppid();

   displayProcessTimes("After getppid() loop:\n");

   exit(EXIT_SUCCESS);
}

The Linux Programming Interface - Memory Mappings

Can Gulmez — Thu, 09 Oct 2025 09:25:35 +0000

Let's continue discussing the Linux programming with mmap() system call.

The mmap() system call creates a new memory mapping in the calling process's virtual address space. There are two types of mapping:

File mapping: A file mapping maps a region of a file directly into the calling process's virtual memory.
Anonymous mapping: An anonymous mapping doesn't have a corresponding file. Instead, the pages of the mapping are initialized to 0.

The memory in one process's mapping may be shared with mappings in other processes (MAP_SHARED). This can occur in two ways:

When two processes map the same region of a file, they share the same pages of physical memory.
A child process created by fork() inherits copies of its parent's mappings, and these mappings refer to the same pages of physical memory as the corresponding mappings in the parent.

We also set the memory mapping as private (MAP_PRIVATE) so that other processes cannot see the content of the memory mapping.

In total, we can use mmap() in four situations:

Private file mapping
Private anonymous mapping
Shared file mapping
Shared anonymous mapping

And don't forget exec() family erase and rebuild the process virtual memory so that memory mapping is lost.

If you type the man 2 mmap and see the its signatures:

void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);
int munmap(void *addr, size_t length);
int msync(void *addr, size_t length, int flags);
void *mremap(void *oldaddr, size_t oldsize, size_t newsize, int flags, ... /* void *newaddr */)

In here:

The addr argument indicates the virtual address at which the mapping is to be located. You should put the NULL so that kernel selects the proper address.
The length argument specifies the size of the mapping in bytes.
The prot argument is a bit mask specifying the protection to be placed on the mapping and can take PROT_NONE, PROT_READ, PROT_WRITE, PROT_EXEC. For example, PROT_READ | PROT_WRITE means that mapping can be read and written but not executed.
The flags argument is a bit mask of options controlling various aspects and can be MAP_PRIVATE and MAP_SHARED.
The fd and offset arguments are just for file mapping. But, in case of anonymous mapping, it is good practice to set fd as -1.

Below is the simple anonymous file mapping program:

#include "../linux.h"

void main(int argc, char *argv[])
{
   char *addr;
   int fd;
   struct stat sb;

   if (argc != 2 || strcmp(argv[1], "--help") == 0)
      usage_error("Wrong command-line usage");

   fd = open(argv[1], O_RDONLY);
   if (fd == -1)
      syscall_error();

   if (fstat(fd, &sb) == -1)
      syscall_error();

   addr = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
   if (addr == MAP_FAILED)
      syscall_error();

   if (write(STDOUT_FILENO, addr, sb.st_size) == -1);
      syscall_error();

   exit(EXIT_SUCCESS);
}

As can be seen above, for file mapping (private or shared), the following steps are applied:

Obtain the file descriptor that is mapped, typically via a call to open().
Use stat() system call to get the file length in bytes.
Pass these variables to mmap() system call call with NULL as start address of mapping.

Below is the another example about shared file mapping:

#include "../linux.h"

#define MEM_SIZE 10

void main(int argc, char *argv[])
{
   char *addr;
   int fd;

   if (argc < 2 || strcmp(argv[1], "--help") == 0)
      usage_error("Wrong command-line usage");

   fd = open(argv[1], O_RDWR);
   if (fd == -1)
      syscall_error();

   addr = mmap(NULL, MEM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
   if (addr == MAP_FAILED)
      syscall_error();

   if (close(fd) == -1)       /* No longer need 'fd' */
      syscall_error();

   printf("Current string=%.*s\n", MEM_SIZE, addr);

   if (argc > 2) {            /* Update contents of region */
      if (strlen(argv[2]) >= MEM_SIZE)
         usage_error("String too long");

      memset(addr, 0, MEM_SIZE); /* Zero out region */
      strncpy(addr, argv[2], MEM_SIZE - 1);
      if (msync(addr, MEM_SIZE, MS_SYNC) == -1)
         syscall_error();

      printf("Copied \"%s\" to shared memory\n", argv[2]);
   }

   exit(EXIT_SUCCESS);
}

In this example, we see the writing 10 bytes to shared memory mapping after the zeroing a partition of file mapping. In addition, we see the msync() system call. It is actually optional but good practice when writing to disk. It ensures that the 10 bytes are written to disk.

In addition to MAP_PRIVATE and MAP_SHARED, Linux allows a number of other values to be included in the mmap() flags argument:

MAP_ANONYMOUS
MAP_FIXED
MAP_LOCKED
MAP_HUGETLB
MAP_NORESERVE
MAP_PRIVATE
MAP_POPULATE
MAP_SHARED
MAP_UNINITIALIZED

Please read the manual page (man 2 mmap) to learn these flags.

When talking about memory mapping and virtual memory layout, I wanna give you some virtual memory operations. There are four main system call:

The mprotect() system call changes the protection on a region of virtual memory.
The mlock() and mlockall() system calls lock a region of virtual memory into physical memory.
The mincore() system call allows a process to determine whether the pages in a region of virtual memory are resident in physical memory.
The madvise() system call allows a process to advise the kernel about its future patterns of usage of a virtual memory region.

Signatures of these system calls:

int mprotect(void *addr, size_t len, int prot);
int mlock(const void *addr, size_t len);
int mlockall(int flags);
int munlock(const void *addr, size_t len);
int munlockall(void);
int mincore(void *addr, size_t length, unsigned char *vec);
int madvise(void *addr, size_t length, int advice);

Below is the simple program about changing the memory protection mapped by mmap() system call.

#include "../linux.h"

#define LEN          (1024 * 1024)
#define SHELL_FMT    "cat /proc/%ld/maps | grep zero"
#define CMD_SIZE     (sizeof(SHELL_FMT) + 20)

void main(int argc, char *argv[])
{
   char cmd[CMD_SIZE];
   char *addr;

   addr = mmap(NULL, LEN, PROT_NONE, MAP_SHARED | 
               MAP_ANONYMOUS, -1, 0);
   if (addr == MAP_FAILED)
      syscall_error();

   /* Display line from /proc/self/maps corresponding to mapping */

   printf("Before mprotect()\n");
   snprintf(cmd, CMD_SIZE, SHELL_FMT, (long) getpid());
   system(cmd);

   /* Change protection on memory to allow read and write access */

   if (mprotect(addr, LEN, PROT_READ | PROT_WRITE) == -1)
      syscall_error();

   printf("After mprotect()\n");
   system(cmd);

   exit(EXIT_SUCCESS);
}

In here, firstly I've mapped a shared anonymous memory. mprotect() changes the memory mapping's from none to read and write protections. To see the this change, we can inspect the /proc/PID/maps file.

Programming and Flashing MCU without any IDE

Can Gulmez — Fri, 03 Oct 2025 09:31:41 +0000

Let's dive into embedded world!

In this post, I will explain the STM32F4 microcontroller programming and flashing without any IDE like STM32Cube IDE.

Let's start with the programming side. The main interface that we use for programming STM32-based microcontroller is the STM32 Cube HAL (Hardware Abstraction Layer) library. It is implemented by vendor, STMicroelectronics. Also we need the CMSIS (Common Microcontroller Software Interface Standard) library developed by ARM. Additionally, linker script, startup code, and similar files are needed.

I'm using the PlatformIO extension in VS Code. It handles the all library dependencies, just install that extension and create a new project. The libraries and binaries will be installed and can be used directly. Don't forget that platformio.ini is the configuration file, edit it according to your microcontroller.

I've written a example program in /src/main.c in the PlatformIO project.

/**
 * Demo Project
 */

#include <stm32f4xx_hal.h>

/**
 * Oscillator and Clock Configuration
 */
void OscClockConfig(void)
{
    /* ... */
}

void main(int argc, char *argv[])
{
        HAL_Init();

    OscClockConfig();

    /* Enable some peripheral clocks over RCC registers */
    __HAL_RCC_GPIOA_CLK_ENABLE();
    __HAL_RCC_GPIOB_CLK_ENABLE();
    __HAL_RCC_GPIOC_CLK_ENABLE();

    /* Configure the PA0 pin just as push-pull output */
    GPIO_InitTypeDef initPA0;
    initPA0.Pin = GPIO_PIN_0;
    initPA0.Mode = GPIO_MODE_OUTPUT_PP;
    initPA0.Pull = GPIO_NOPULL;
    initPA0.Speed = GPIO_SPEED_FREQ_LOW;    /* doesn't matter */
    HAL_GPIO_Init(GPIOA, &initPA0);

    /* Set the PA0 pin to logic 1 (+3.3V) */
    HAL_GPIO_WritePin(GPIOA, GPIO_PIN_0, SET);

    while (1);
}

To create the proper binary (ELF for GNU/Linux and PE for Windows) that will be flashed into microcontroller, we need to compile it:

$ pio run

Don't forget that run this command where platformio.ini is. The output of this command will be like this:

Processing genericSTM32F446RE (platform: ststm32; board: genericSTM32F446RE; framework: stm32cube)
---------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F446RE.html
PLATFORM: ST STM32 (19.2.0) > STM32F446RE (128k RAM. 512k Flash)
HARDWARE: STM32F446RET6 180MHz, 128KB RAM, 512KB Flash
DEBUG: Current (blackmagic) External (blackmagic, jlink, stlink)
PACKAGES: 
 - framework-stm32cubef4 @ 1.28.1 
 - tool-ldscripts-ststm32 @ 0.2.0 
 - toolchain-gccarmnoneeabi @ 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 59 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Compiling .pio/build/genericSTM32F446RE/FrameworkHALDriver/Src/stm32f4xx_hal.o
Compiling .pio/build/genericSTM32F446RE/FrameworkHALDriver/Src/stm32f4xx_hal_adc.o

...

Compiling .pio/build/genericSTM32F446RE/FrameworkHALDriver/Src/stm32f4xx_ll_utils.o
Compiling .pio/build/genericSTM32F446RE/src/main.o
src/main.c:15:6: warning: return type of 'main' is not 'int' [-Wmain]
 void main(int argc, char *argv[])
      ^~~~
Compiling .pio/build/genericSTM32F446RE/FrameworkCMSISDevice/gcc/startup_stm32f446xx.o
Compiling .pio/build/genericSTM32F446RE/FrameworkCMSISDevice/system_stm32f4xx.o
Archiving .pio/build/genericSTM32F446RE/libFrameworkCMSISDevice.a
Indexing .pio/build/genericSTM32F446RE/libFrameworkCMSISDevice.a
Linking .pio/build/genericSTM32F446RE/firmware.elf
Checking size .pio/build/genericSTM32F446RE/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.0% (used 40 bytes from 131072 bytes)
Flash: [          ]   0.2% (used 1148 bytes from 524288 bytes)
Building .pio/build/genericSTM32F446RE/firmware.bin
============================================== [SUCCESS] Took 20.12 seconds ==============================================

After this command finished, there will be two files named firmware.bin and firmware.elf under ./pio/build directory.

firmware.bin includes the pure raw machine code that will be written to microcontroller. To flash this, you have to declare the base address of flash memory (0x08000000 in case). firmware.elf includes the pure the machine code plus debug info, sections or so on. This is primarily used for debugger, GDB. So if you look at the sizes, firmware.elf will be much bigger.

After producing the binaries and before flashing it, we want sometimes to inspect binary contents. For example, let's look at the section headers:

$ arm-none-eabi-objdump -h firmware.elf

Output:

firmware.elf:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .isr_vector   000001c4  08000000  08000000  00010000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         00000470  080001c4  080001c4  000101c4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .rodata       00000000  08000634  08000634  0002000c  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  3 .ARM.extab    00000000  08000634  08000634  0002000c  2**0
                  CONTENTS
  4 .ARM          00000000  08000634  08000634  0002000c  2**0
                  CONTENTS
  5 .preinit_array 00000000  08000634  08000634  0002000c  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  6 .init_array   00000004  08000634  08000634  00010634  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  7 .fini_array   00000004  08000638  08000638  00010638  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .data         0000000c  20000000  0800063c  00020000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .bss          0000001c  2000000c  08000648  0002000c  2**2
                  ALLOC
 10 ._user_heap_stack 00000600  20000028  08000648  00020028  2**0
                  ALLOC
 11 .ARM.attributes 0000002a  00000000  00000000  0002000c  2**0
                  CONTENTS, READONLY
 12 .comment      0000007e  00000000  00000000  00020036  2**0
                  CONTENTS, READONLY
 13 .debug_frame  0000002c  00000000  00000000  000200b4  2**2
                  CONTENTS, READONLY, DEBUGGING, OCTETS

In here, we see the many sections. Each section include different stuffs. The machine code will be in .text section. So it is the main target for reverse-engineering works. Apart from that .data, .bss and .rodata sections will contain the various variable declarations. .isr_vector is the ARM-specific section that includes the ISRs (Interrupt Service Routines). It is related to the interrupt mechanism in ARM Cortex. .init_array and .fini_array sections include the constructor/destructor machine code. These run before/after the main() (entry-point) function. .debug_frame is primarily used by GDB debugger. There are also ARM-specific sections that I don't know actually.

To display the machine code and its corresponding assembly commands, run this:

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

Or we can see the HAL functions used in the program:

$ arm-none-eabi-strings firmware.elf | grep HAL_*

HAL_NVIC_SetPriority
HAL_GPIO_WritePin
HAL_MspInit
HAL_GPIO_Init
HAL_SYSTICK_Config
HAL_Init
HAL_NVIC_SetPriorityGrouping
HAL_InitTick

Actually debugging a firmware is the huge topic and deserves a alone post so that I will go with the flashing phase.

To flash a STM32 microcontroller, we have a few options:

openocd
st-flash
dfu-util

Before the selecting right tool, we need to determine the programming interface that we're current using. Two interfaces shines in embedded world: SWD (Serial Wire Debug) and USB. For ARM-based microcontrollers, SWD is the standard programming/debugging interface. Most modern microcontrollers, additionally, support DFU (Device Firmware Update) interface to program microcontroller over USB. If you plan to use SWD interface, you need a hardware called ST-LINK. In USB interface, you just need USB cable. But to put the microcontroller in DFU mode, you put the BOOT0 pin to logic 1 (+3.3V). Both interfaces have advantages/disadvantages. You need to select the right tool for your case.

For this post, I have SWD interface and ST-LINK device. To list and check ST-LINK connection, lsusb can be used:

$ lsusb

Output:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0438:7900 Advanced Micro Devices, Inc. Root Hub
Bus 001 Device 003: ID 0bda:c024 Realtek Semiconductor Corp. Bluetooth Radio 
Bus 001 Device 004: ID 174f:116a Syntek EasyCamera
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 0483:374b STMicroelectronics ST-LINK/V2.1
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Let's start with OpenOCD (Open On-Chip Debugger), if you have SWD interface and ST-LINK, the mostly reliable way is to use OpenOCD. It's open source project that supports multiple interfaces and microcontrollers. You can think it as a bridge between ST-LINK and microcontroller. We can use OpenOCD in two different ways. If you just want flashing firmware:

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

Output:

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 : clock speed 2000 kHz
Info : STLINK V2J33M25 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.223622
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
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
[stm32f4x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800308c msp: 0x20020000
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
** Programming Started **
Info : device id = 0x10006421
Info : flash size = 512 KiB
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
shutdown command invoked

Don't forget that if you want to flash firmware.bin, explicitly, declare the flash address:

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

We also want to debug the firmware beside the flashing it. Firstly, open a OpenOCD session in a terminal:

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

Output:

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.229921
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

After that in another terminal, with GDB:

$ arm-none-eabi-gdb firmware.elf

You will be in GDB session. In here, you have to bind 3333 port and then load the firmware:

(gdb) target remote localhost:3333
(gdb) monitor reset halt
(gdb) load

At the end, you will see the flashed sections:

Loading section .isr_vector, size 0x1c4 lma 0x8000000
Loading section .text, size 0x470 lma 0x80001c4
Loading section .init_array, size 0x4 lma 0x8000634
Loading section .fini_array, size 0x4 lma 0x8000638
Loading section .data, size 0xc lma 0x800063c
Start address 0x80005c8, load size 1608
Transfer rate: 3 KB/sec, 321 bytes/write.

Firmware is loaded successfully 🥳.

After this phase, we can start debugging. I will show some commonly used commands but as I said before, this post focus on programming and flashing so that debugging is another post's topic.

(gdb) info registers        // show register information
(gdb) break main            // put a breakpoint at main()
(gdb) continue              
(gdb) next                  
(gdb) step
(gdb) x/1wx 0x40023830      // examine the RCC register

Another tool is st-flash. You can think that it's STM32-version of OpenOCD. It uses SWD interface and it is used like this:

$ st-flash write firmware.bin 0x8000000

Output:

st-flash 1.8.0
2025-10-03T12:27:22 INFO common.c: STM32F446: 128 KiB SRAM, 512 KiB flash in at least 128 KiB pages.
file firmware.bin md5 checksum: 19739c7292a119ff141424e01acdf2e8, stlink checksum: 0x0001c4f0
2025-10-03T12:27:22 INFO common_flash.c: Attempting to write 1608 (0x648) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000 -> Flash page at 0x8000000 erased (size: 0x4000)
2025-10-03T12:27:22 INFO flash_loader.c: Starting Flash write for F2/F4/F7/L4
2025-10-03T12:27:22 INFO flash_loader.c: Successfully loaded flash loader in sram
2025-10-03T12:27:22 INFO flash_loader.c: Clear DFSR
2025-10-03T12:27:22 INFO flash_loader.c: enabling 32-bit flash writes
2025-10-03T12:27:22 INFO common_flash.c: Starting verification of write complete
2025-10-03T12:27:22 INFO common_flash.c: Flash written and verified! jolly good!

dfu-util is a bit different. Despite openocd and st-flash use SWD interface, dfu-util is used with USB connection. Don't forget that you have to put the microcontroller in DFU mode by setting the BOOT0 pin to logic 1 (+3.3V). After that reset the microcontroller and then flash the firmware:

$ dfu-util -a 0 -s 0x08000000:leave -D firmware.bin