The following are the prerequisites for the chapter:

• STM32CubeIDE: https://www.st.com/en/development-tools/stm32cubeide.html
• GNU Arm Embedded Toolchain (gcc-arm-none-eabi-10.3-2021.10-win32.exe): https://developer.arm.com/downloads/-/gnu-rm
• OpenOCD: https://github.com/xpack-dev-tools/openocd-xpack/releases
• Notepad++: https://notepad-plus-plus.org/downloads/v8.5.8/
• STM32F11 reference manual: https://www.st.com/resource/en/reference_manual/rm0383-stm32f411xce-advanced-armbased-32bit-mcus-stmicroelectronics.pdf
• STM32F411 datasheet: https://www.st.com/resource/en/reference_manual/rm0383-stm32f411xce-advanced-armbased-32bit-mcus-stmicroelectronics.pdf
• NUCLEO-F411 user manual: https://www.st.com/resource/en/user_manual/um1724-stm32-nucleo64-boards-mb1136-stmicroelectronics.pdf
• Cortex-M4 generic user guide: https://developer.arm.com/documentation/dui0553/latest/

In this section, we will explore the essential tools that form the backbone of our development process. Understanding these tools is important, as they will be our companions in transforming ideas into functioning firmware.

When selecting tools for firmware development, we have two primary options.

• IDEs: An IDE is a unified software application offering a Graphical User Interface (GUI) tailored to crafting software – in our context, firmware. Popular IDEs for microcontroller firmware development include the following:
• Keil uVision (also known as Keil MDK): Developed by ARM Holdings
• STM32CubeIDE: Developed by STMicroelectronics
• IAR Embedded Workbench: Developed by IAR Systems

  These IDEs boast a GUI-centric design, enabling users to conveniently create new files, build, compile, and step through code lines interactively. For the demonstrations and exercises in this book, we’ll use the STM32CubeIDE. It has all the requisite features and is generously available for free, without any code size constraints.

• Toolchains: At its core, a toolchain is a cohesive set of development tools, sequenced in distinct stages, to produce the final firmware build for the target microcontroller. This approach bypasses the comfort of a GUI. Instead, firmware is written using basic text editors such as Notepad or Notepad++, with the command line used to execute the various phases of the build process –commands such as assemble, compile, and link are often used. In this book, we’ll use the open source GNU Arm Embedded Toolchain. Based on the renowned open source GNU Compiler Collection (GCC), this integrates a GCC compiler tailored for ARM, the GNU Debugger (GDB) debugger, and several other invaluable utilities.

In the following section, we will carefully go through the process of setting up our preferred IDE, the STM32CubeIDE.

Setting up the STM32CubeIDE

Throughout this book, we’ll use both the STM32CubeIDE and the GNU Arm Embedded Toolchain to develop our firmware. Leveraging an IDE such as STM32CubeIDE enables us to easily analyze and compare the linker script and startup files, autogenerated by the IDE, against those we’ll construct from the ground up.

Let’s start by downloading and installing STM32CubeIDE:

1. Launch your web browser and navigate to st.com.
2. Click on STM32 Developer Zone, and then select STM32CubeIDE.

Figure 1.1: The home page of st.com

3. Scroll down to the All software versions section of the page and click on Download Software. You’ll need to log into your ST account before proceeding with the download.

Figure 1.2: The All software versions section of the stm32cubeide page

4. If you don’t have an account, click on Login/Register to sign up. If you already have one, simply log in.
5. Complete the registration form with your first name, last name, and email address.
6. Click on Download to start the download process. A .zip file will be downloaded into your Downloads folder.

Let’s install the STM32CubeIDE:

1. Unzip the downloaded package.
2. Double-click the st-stm32cubeide file to initiate the installer.
3. Retain default settings by clicking Next throughout the setup process.
4. On the Choose Components page, ensure that both SEGGER J-Link drivers and ST-LINK drivers are selected. Then, click Install.

Figure 1.3: The installer showing the Choose Components page

Having successfully installed STM32CubeIDE on our computer, we will now proceed to configure our alternate development tool, the GNU Arm Embedded Toolchain.

Setting up the GNU Arm Embedded Toolchain

In this section, we will go through the process of setting up the GNU Arm Embedded Toolchain – an important tool for developing firmware for ARM-based microcontrollers:

1. Launch your web browser and navigate to https://developer.arm.com/downloads/-/gnu-rm.
2. Scroll down the page to find the download link appropriate for your operating system. For those of you using Windows, like myself, opt for the .exe version. For Linux or macOS users, choose the corresponding .tar file for your operating system.
3. After the download completes, double-click the installer to begin the installation process.
4. Read through the license agreement. Then, choose to install in the default folder location by clicking Install.

Figure 1.4: The GNU Arm Embedded Toolchain installer

5. When the installation is complete, ensure that you check the Add path to environment variable option.

Figure 1.5: The installer showing the Add path to environment variable option

6. Click Finish to finalize the setup.

Setting up OpenOCD

For firmware development with the GNU Arm Toolchain, OpenOCD plays an integral role, facilitating both the downloading of firmware into our microcontroller and the debugging of code in real time.

Let’s set up OpenOCD:

1. Launch your web browser and navigate to https://openocd.org/pages/getting-openocd.html.
2. Scroll to the section titled Unofficial binary packages.
3. Click on the link for multiplatform binaries.

Figure 1.6: The Unofficial binary packages section

4. Identify the latest version compatible with your operating system. For an exhaustive list, click on Show all 14 assets.

Figure 1.7: The OpenOCD packages

5. For Windows users, download the win32-x64.zip version. For Linux or macOS users, download the corresponding .tar file for your operating system.
6. Once downloaded, unzip the package.
7. Navigate to the extracted folder, and then the bin subfolder. Here, you’ll find the openocd.exe application. This is the application we shall call in the command prompt together with the specific script of our chosen microcontroller, in order to debug or download code onto the microcontroller.

Within the xpack-openocd-0.12.0-2 | openocd | scripts directory structure, you’ll find scripts tailored for various microcontrollers and development boards.

Next, we need to add OpenOCD to our environment variables:

1. Begin by relocating the entire openocd folder to your Program Files directory.

Figure 1.8: OpenOCD moved to Program Files, showing the path to the bin folder

2. Copy the path to the openocd bin folder.
3. Right-click on This PC, and then choose Properties.
4. Search for and select Edit the system environment variables.

Figure 1.9: The This PC properties page

5. Click the Environment Variables button in the System Properties pop-up window.

Figure 1.10: The System Properties pop-up window

6. Under the User variables section of the Environment Variables popup, double-click the Path entry.

Figure 1.11: The Environment Variables popup

7. In the Edit environment variable popup, click on New to create a row for a new path entry.
8. Paste the previously copied OpenOCD path into this new row.
9. Confirm your changes by clicking OK on the various pop-up windows.

Figure 1.12: The Edit environment variable popup

Finally, we have successfully completed the setup process. We have configured two essential, standalone tools to develop firmware for STM32 microcontrollers – the STM32CubeIDE for an IDE, and the GNU Arm Embedded Toolchain, complemented by OpenOCD, to develop and debug our firmware without an IDE.

Next, we will turn our attention to our development board.

In this segment of the chapter, we will delve into the specifications and features of the development board selected for this book.

Understanding the role of a development board

Firstly, let’s clarify the concept of a development board. It’s essential to note that a development board is not synonymous with a microcontroller. While a development board might derive part of its name from the microcontroller mounted on it, it would be a misnomer to refer to the board itself as the microcontroller. A development board allows us to validate our firmware on the exact microcontroller variant we aim to deploy in our final product. Consequently, the firmware tested on our development board is assured to operate identically on the microcontroller in the end product. This is why companies such as STMicroelectronics offer a diverse range of development boards, tailored to each microcontroller in their portfolio.

It’s also essential to contrast the role of a development board with prototyping boards, such as Arduino. While prototyping boards (which might not house the microcontrollers intended for the final product) serve as preliminary testing platforms, development boards elevate this process. They enable us to rigorously test concepts and the performance evaluation of our firmware on the designated microcontroller meant for bulk product manufacturing. For the purposes of this book, our focus will be on the NUCLEO-F411 development board.

An overview of the NUCLEO-F411 Development Board

The NUCLEO-F411 development board is equipped with an STM32F411RE microcontroller, capable of a peak operating frequency of 100MHz. It comes with a generous 512 Kbytes of flash memory and 128 Kbytes of SRAM. Furthermore, the board is equipped with several columns of berg pins, allowing us to effortlessly make connections using jumper wires to interface with a variety of modules and components – from sensors and motors to LEDs. For quick and straightforward input/output firmware tests, the board also features a built-in user button and LED, eliminating the immediate need for external components.

Figure 1.13: The NUCLEO-F411 development board

Now that we’re familiar with the development board, let’s delve into the various types of documentation that are essential for a comprehensive understanding and programming of the development board.

Our main objective in this book is to write firmware code that interacts directly with the registers of our microcontroller. This means there’s no abstraction or intermediary library between our code and the target microcontroller. To achieve this, it’s important to grasp the internal architecture of the microcontroller, understand the addresses of each register we interact with, and know the functions of relevant bits within those registers. This is where datasheets and manuals come in. Manufacturers provide these documents for users to understand their products, which in our case refers to the microcontroller core architecture, the microcontroller, and the development board.

Two distinct companies play roles in the making of our development board. The first is ARM Holdings, which licenses processor and microcontroller core architecture designs to semiconductor manufacturing firms such as STMicroelectronics, Texas Instruments, and Renesas. These manufacturers then produce the physical microcontroller or processor based on the licensed designs from ARM, often with their custom additions. This explains why two different microcontrollers from separate manufacturers might share the same microcontroller core. For instance, both the TM4C123 from Texas Instruments and STM32F4 from STMicroelectronics are based on the ARM Cortex-M4 core.

Since our chosen development board, the NUCLEO-F411 from STMicroelectronics, is based on the ARM Cortex-M4 microcontroller core, in the following sections, we’ll delve into the documentation for the board, its integrated microcontroller, and the underlying core.

Understanding STMicroelectronics’ documentation

A significant reason for the popularity of STM32 microcontrollers is STMicroelectronics’ continued commitment to providing comprehensive support. This includes well-organized documentation and various firmware development resources.

STMicroelectronics has a range of documents, each following a specific naming convention. Let’s discuss those relevant to our work:

• Reference Manual (RM): All RMs start with the letters RM, followed by a number. For instance, the RM for our microcontroller is RM0383. This document details every register in our microcontroller, clarifying each bit’s role and providing insights on register configurations.
• Datasheet: The datasheet is named after the microcontroller, so for the STM32F411 microcontroller, the datasheet is simply called STM32F411. This document provides a functional overview of the microcontroller, a complete memory map, a block diagram showcasing the microcontroller’s peripherals and connecting buses, as well as the pinout and electrical characteristics of the microcontroller.
• UM (User Manual): Starting with the letters UM and followed by a number, such as UM1724 for our NUCLEO-F411, this document focuses on the development board. It describes how components on our board, such as LEDs and buttons, are connected to specific ports and pins of the microcontroller.

The generic user guide by ARM

ARM provides documents for every microcontroller and processor core they design. Important to our discussion is the generic user guide for our microcontroller core. As we’re using the STM32F411, which is based on the ARM Cortex-M4 core, we’ll refer to the Cortex-M4 generic user guide.

This means that if we were using an STM32F7 microcontroller, which is based on the ARM Cortex-M7 core, then we would need to get the Cortex-M7 generic user guide. The naming convention of this document is simply the name of the microcontroller core + the phrase generic user guide.

As the name implies, this document provides information generic to the specific microcontroller core. This means that the information provided in the Cortex-M4 generic user guide applies to all microcontrollers based on the Cortex-M4 core, irrespective of the manufacturers of those microcontrollers. In contrast, the information provided in the STMicroelectronics documentation applies to only STMicroelectronics’ microcontrollers.

Figure 1.14: The relationship between the development board, microcontroller, and microcontroller core

Why do we need the generic user guide?

The generic user guide provides information on the core peripherals of the processor core. As the term suggests, these core peripherals are consistent across all microcontrollers, based on a specific core. The Cortex-M4 core has five core peripherals – the System Timer, Floating-Point Unit, System Control Block, Memory Protection Unit, and the Nested Vectored Interrupt Controller. When developing bare-metal drivers for these peripherals, the generic user guide is the definitive source for the essential details.

Additionally, the guide provides information on the microcontroller core’s Instruction Set, as well as the Programmer’s Model, Exception Model, fault handling, and power management.

Getting the documents

To obtain the aforementioned documents, you can use the following search phrases on Google:

• RM: Either STM32F11 Reference Manual or RM0383.
• Datasheet: STM32F411 Datasheet.
• UM: Nucleo-F11 User Manual or UM1724.
• Generic user guide: Cortex-M4 Generic User Guide

Direct links to these documents are also available, in the Technical requirements section of this chapter.

Before analyzing the key areas of the various documents to program our development board, let’s first take a closer look at the STM32CubeIDE we installed earlier. We will familiarize ourselves with its features and functionalities in the next section.

When you launch STM32CubeIDE for the first time, you’ll see the Information Center. This center offers quick access to a number of valuable resources for STM32 firmware development.

To exit the Information Center, simply click the X on its tab. If you wish to revisit it later, simply navigate to Help | Information Center.

Figure 1.15: Information Center

The STM32CubeIDE is based on the Eclipse framework, and therefore, the layout and elements are similar to those of other Eclipse-based IDEs.

Let’s go through the process of creating a new project:

1. Either click Create a New STM32 project in the empty Project Explorer pane or select File | New | STM32 Project.

Figure 1.16: A workspace showing an empty Project Explorer pane

2. You will be presented with the Target Selection window to select the microcontroller or development board for your project.
3. Click the Board Selector tab.
4. Enter NUCLEO-F411 into the Commercial Part Number field.

Figure 1.17: The Target Selection window

5. From the displayed board list, select NUCLEO-F11RE, and then click Next.

Figure 1.18: The board list with NUCLEO-F411 selected

6. Give the project a name.
7. For Targeted Project Type, select Empty.

Figure 1.19: The Setup STM32 project window

8. Click Finish to create the project.

You will see the new project, containing all the necessary startup files and linker scripts, in the Project Explorer pane.

Figure 1.20: The Project Explorer pane showing a new project

The most frequently used control icons are the New, Build, and Debug icons.

Figure 1.21: The control icons

Let’s look closely at the functions of these icons:

• The New icon: This icon allows us to create various files, including source code, header files, projects, libraries, and more. This function is also accessible via File | New.
• The Build icon: Used for building projects. This functionality can also be accessed by right-clicking on a project and selecting Build Project.
• The Debug icon: This launches a debug configuration to facilitate project debugging. This functionality is also available by right-clicking a project and selecting Debug Project.

These control icons provide quick access to essential functions, significantly enhancing productivity and streamlining the development process.

In this chapter, we set out to create a robust environment for embedded firmware development, focusing on the careful selection and setup of essential tools. Each tool we selected plays a crucial role in the efficient development of firmware for microcontrollers. We explored the installation processes of STM32CubeIDE, the GNU Arm Embedded Toolchain, and OpenOCD, laying a solid groundwork for our development activities.

We then introduced the NUCLEO-F411 development board, equipped with an STM32F411RE microcontroller, as our experimental platform, and we spent time identifying some of the components on the board.

We also emphasized the importance of knowing the different types of datasheets and reference manuals, equipping us with the ability to quickly access detailed information about a microcontroller’s architecture and functionalities.

Moving on to the next chapter, we will leap into developing our first bare-metal firmware, using only the documentation we have compiled as our guide.