Introduction
In this post, we'll explore the LedBlink project, a simple LED blink application that uses the HAL library on an STM32F4 microcontroller. Along the way, we'll also dive into the architecture, build process, and use of linker scripts, explaining how various components come together to produce the final firmware. This post will guide you through cleaning, building, and understanding the architecture of the project.
LedBlink Project Overview
The LedBlink project can be found in the repository:
This project is designed to blink the User's Green LED (LD2) connected to PA5 on the STM32F4 board. The HAL library is used for accessing hardware abstractions.
Source Code Explanation
At its core, the project has a simple structure. The HAL's toggle pin function is placed inside an infinite while(1) loop with a delay, making the LED blink continuously.
Project Architecture
The project's structure is straightforward and divided into key components. When the project is cleaned, four folders and four files remain, each playing an important role.
Folder Breakdown:
1. Includes
This isn't an actual folder in the file explorer but is visible within the IDE. It contains a list of preprocessor includes, which are configured under:
Project Settings -> C/C++ Build -> Settings -> Tool Settings -> MCU GCC Compiler -> Include Paths.
These include paths are essential for successful compilation.
2. Core
This folder holds the `main.c` and `main.h` files. It also contains the startup code, written in assembly, that handles the initial boot sequence of the microcontroller.
3. Drivers
This folder contains both HAL and CMSIS drivers, provided by the STM32CubeIDE. These drivers abstract the hardware interactions, simplifying the process of toggling GPIO pins, handling interrupts, and more.
4. Debug
This is where temporary files (such as `.o`, `.hex`, `.bin`, and `.elf`) are generated during the build process. The Makefile and linker outputs are also stored here.
Cleaning the Project
Before diving into the build process, let’s talk about cleaning the project. Cleaning removes temporary files that were generated during previous builds. Here's how it works:
1. When you select clean, it triggers the `clean` target in the Makefile.
2. The command deletes all temporary files like `.o`, `.cyclo`, `.su`, and `.d`, as well as build outputs such as `.hex` and `.elf`.
3. Since the build system relies on UNIX-based commands, running the clean command via Windows CMD might not work. It’s recommended to use Git Bash for successful execution.
The Build Process Explained
1. The Compiler
The "arm-none-eabi-gcc" compiler is used for the build process. However, running this in Windows CMD might cause issues because the build environment is designed around UNIX commands. To avoid these issues, use Git Bash.
2. Include Paths
During the manual build, you may encounter issues if the include paths are not properly set. The STM32CubeIDE automatically sets up these include paths for you in the background. If you're building the project outside the IDE, make sure to reference the correct include paths located in the "Includes" folder in your project settings.
3. Makefile Execution
When you select build, the Makefile comes into play. Here’s how it unfolds:
1. First, the `all` target is processed, which depends on the `main-build` target.
2. The `main-build` target has dependencies on `LedBlink.elf` and `secondary-outputs`.
4. Building the ELF File
The LedBlink.elf file is the primary output of the build process. Once the file is successfully built, the message `Finished building target: LedBlink.elf` is echoed to the console.
5. Memory Size Information
After building the ELF file, the size of each memory section (text, data, bss) is printed using the ARM `size` utility. Here's an example output:
text data bss dec hex filename
10216 20 1708 11944 2ea8 LedBlink.elfThis output gives you an idea of how much Flash (text), RAM (data and bss) is being consumed by the firmware.
6. Final Outputs
Once the ELF file is built, the process continues to generate additional outputs:
`Finished building: default.size.stdout``Finished building: LedBlink.hex``Finished building: LedBlink.list`These are essential files for flashing the firmware onto the microcontroller.
Understanding Secondary Outputs
The secondary-outputs target is responsible for printing the size of the generated ELF file using the `arm-none-eabi-size` utility. This is an important step for embedded developers, as it helps ensure that the program fits within the memory constraints of the microcontroller.
Conclusion
The LedBlink project offers a solid introduction to working with STM32 microcontrollers using the HAL library and STM32CubeIDE. By understanding the project architecture, clean and build processes, and the importance of linker scripts, you can streamline your development process and gain deeper insight into embedded programming.
If you’d like to learn more about linker scripts or other embedded system topics, feel free to explore my other blog posts!
Comments