Arm none eabi toolchain windows

The GNU Embedded Toolchain for Arm is a ready-to-use, open source suite of tools
for C, C++ and Assembly programming targeting Arm Cortex-M and Cortex-R family
of processors. It includes the GNU Compiler (GCC) and is available free of
charge directly from Arm for embedded software development on Windows, Linux and
macOS operating systems.

This repository is the original Windows version of the GNU Compiler from Arm
packaged for Visual Studio Code:

GNU Arm embedded toolchain

Install

In Visual Studio Code goto extensions (Shift+Ctrl+X), search for ‘metalcode-eu
and install the extension that is suited for your operating system.

The extension has four paths for the toolchain. You can use this in the
tasks.json.

  • arm-none-eabi.bin
  • arm-none-eabi.include
  • arm-none-eabi.lib
  • arm-none-eabi.libgcc

Here is an example of tasks.json for GNU make.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "build firmware",
      "type": "shell",
      "command": "make test",
      "options": {
        "env": {
          "INCLUDE": "${config:arm-none-eabi.include}",
          "LIB": "${config:arm-none-eabi.lib}",
          "LIBGCC": "${config:arm-none-eabi.libgcc}/thumb/v6-m/libgcc.a",
        }
      },
      "osx": {
        "options": {
          "env": {
            "PATH": "${config:arm-none-eabi.bin}:${env:PATH}",
          }
        },
      },
      "linux": {
        "options": {
          "env": {
            "PATH": "${config:arm-none-eabi.bin}:${env:PATH}",
          }
        },
      },
      "windows": {
        "options": {
          "env": {
            "PATH": "${config:arm-none-eabi.bin};${env:PATH}",
          }
        },
      },
      "group": {
        "kind": "build",
        "isDefault": true,
      },
      "problemMatcher": "$gcc"
    }
  ]
}

With the following makefile:

.PHONY: test

test:
	@echo $(PATH)
	@echo $(INCLUDE)
	@echo $(LIB)
	@echo $(GCCLIB)

Release Notes

Version 0.1.6

Version 8-2018-q4-major for Windows
Released: December 20, 2018

Version 0.1.2

Fixed typo in path to repository causing a wrong link in the marketplace.

Added a path to the libgcc files.

  • arm-none-eabi.libgcc

When you do bare metal development, you often exclude all standard libraries
but you still need libgcc.a for integer division etc. The path to this file
contains a version number that changes with every release of the toolchain.
Using this variable you do not need to update your makefiles with every new
release of the toolchain.

Version 0.1.0

Version 7-2018-q2-update for Windows

Version 0.0.5

Operating system specific PATH environment variable.

Version 0.0.2

Changed ${env:HOME} to ${env:USERPROFILE}.

Version 0.0.1

GNU Make 4.2.1

Version 7-2017-q4-major for Windows
Released: December 18, 2017

GNU Arm embedded toolchain for Windows

The GNU Embedded Toolchain for Arm is a ready-to-use, open source suite of tools
for C, C++ and Assembly programming targeting Arm Cortex-M and Cortex-R family
of processors. It includes the GNU Compiler (GCC) and is available free of
charge directly from Arm for embedded software development on Windows, Linux and
macOS operating systems.

This repository is the original Windows version of the GNU Compiler from Arm
packaged for Visual Studio Code:

GNU Arm embedded toolchain

Install

In Visual Studio Code goto extensions (Shift+Ctrl+X), search for ‘metalcode-eu
and install the extension that is suited for your operating system.

The extension has four paths for the toolchain. You can use this in the
tasks.json.

  • arm-none-eabi.bin
  • arm-none-eabi.include
  • arm-none-eabi.lib
  • arm-none-eabi.libgcc

Here is an example of tasks.json for GNU make.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "build firmware",
      "type": "shell",
      "command": "make test",
      "options": {
        "env": {
          "INCLUDE": "${config:arm-none-eabi.include}",
          "LIB": "${config:arm-none-eabi.lib}",
          "LIBGCC": "${config:arm-none-eabi.libgcc}/thumb/v6-m/libgcc.a",
        }
      },
      "osx": {
        "options": {
          "env": {
            "PATH": "${config:arm-none-eabi.bin}:${env:PATH}",
          }
        },
      },
      "linux": {
        "options": {
          "env": {
            "PATH": "${config:arm-none-eabi.bin}:${env:PATH}",
          }
        },
      },
      "windows": {
        "options": {
          "env": {
            "PATH": "${config:arm-none-eabi.bin};${env:PATH}",
          }
        },
      },
      "group": {
        "kind": "build",
        "isDefault": true,
      },
      "problemMatcher": "$gcc"
    }
  ]
}

With the following makefile:

.PHONY: test

test:
	@echo $(PATH)
	@echo $(INCLUDE)
	@echo $(LIB)
	@echo $(GCCLIB)

Release Notes

Version 0.1.6

Version 8-2018-q4-major for Windows
Released: December 20, 2018

Version 0.1.2

Fixed typo in path to repository causing a wrong link in the marketplace.

Added a path to the libgcc files.

  • arm-none-eabi.libgcc

When you do bare metal development, you often exclude all standard libraries
but you still need libgcc.a for integer division etc. The path to this file
contains a version number that changes with every release of the toolchain.
Using this variable you do not need to update your makefiles with every new
release of the toolchain.

Version 0.1.0

Version 7-2018-q2-update for Windows

Version 0.0.5

Operating system specific PATH environment variable.

Version 0.0.2

Changed ${env:HOME} to ${env:USERPROFILE}.

Version 0.0.1

GNU Make 4.2.1

Version 7-2017-q4-major for Windows
Released: December 18, 2017

Настройка Toolchain(а) для сборки артефактов под STM32. x86-64, Win, Eclipse, GCC, Make, GDB, ST-LinkV2

В этом тексте я расскажу какой путь проходят исходники с момента написания до момента исполнения на микроконтроллере и как сварить прошивку. Также прокопаю тему как настроить ToolChain из бесплатных утилит. В этом тексте я покажу на что следует обратить внимание при запуске первого проекта на ARM Cortex-M чипах. Этот текст, в сущности, пояснение того, что происходит под капотом большинства IDE (IAR, Keil, CodeComposerStudio и пр.). Можете читать это как курс молодого боевика бойца.

Что же мне потребуется накатить на свой NetTop для разработки под STM32?

Вот список утилит с которыми скорее всего предстоит столкнуться при разработке прошивок для чипов STM32.

Программа/Утилита

Назначение

STM32 ST-LINK Utility.exе 

GUI прошивальщик по SWD/JTAG

ST-LINK_CLI.exe

CLI прошивальщик по SWD/JTAG

Putty /TeraTerm/HTerm

Терминалы Serial порта

STM Studio

Отрисовывать графики переменных из ячеек RAM памяти

Cygwin

Набор Unix утилит для Windows

pdf reader

браузер PDF файлов с документацией

python

интерпретатор языка Python

Cppcheck

Статический анализатор кода

git-bash.exe

Система управления версиями исходных кодов + удобны Unix CLI терминал

WinMerge

Сравнение текстовых файлов с подсветкой

ST-LINK_gdbserver.exe

Отладочный сервер

WinRAR

распаковка архивов с документацией от вендора

GNU Tools ARM Embedded

Компилятор для ARM

Atollic TrueStudio

Набор утилит

Tor Browser

Web Browser для скачивания утилит и документации из санкционных территорий

Jenkins

Сервер сборки артефактов

hexdump /hexedit

просмотрщик бинарных файлов

grep

поиск подстрок в кодовой базе

find

поиск файла в файловой системе по регулярному выражению для его имени

STM32CubeMX

Генератор базового кода с примерами

clang format

автоматические выравнивание отступов

Notepad++

вспомогательный текстовый редактор специально для коммит сообщений

Eclipse IDE for C/C++ Developers 

текстовый редактор

Фаза 1. Установка текстового редактора

Так как любая программа это прежде всего текст, то надо установить какой-нибудь текстовый редактор.

Предлагаю Eclipse IDE for C/C++ Developers так как у него весьма удобные HotKeys. Для ускорения написания кода.

Плюс в Eclipse приятное синее выделение.

Еще Eclipse мгновенно запускается. Как по мне качество текстового редактора определяется тем как часто вам приходится пользоваться мышкой. В хорошем текстовом редакторе мышка вообще не нужна. Eclipse один из таких текстовых редакторов.

Установить Eclipse IDE for C/C++ Developers можно отсюда
https://www.eclipse.org/downloads/packages/

Установка заключается в распаковке скаченного архива в удобное место. В ОС Windows можно устанавливать Eclipse в корень диска С.

Программа запускается с помощью исполняемого файла eclipse.exe, который находится в распакованной папке. 

При первом запуске Eclipse надо выбрать рабочую папку (workspace). В этой папке Eclipse будет по умолчанию создавать проекты.

Настройка проекта в Eclipse

Настройки текстового редактора содержатся в файлах .project, .cproject. Важно снять галочку с пункта Makefile generation. В поле Build location прописать относительный путь к папке, которая содержит Makefile.

Настроить параллельную сборку чтобы ускорить цикл ToolChain(а). Это делается во вкладке Behavior

После этого инициировать сборки можно горячей клавишей Ctrl+B.

Фаза 2. Накатывание ToolChain(а) GCC под ARM для Cross компиляции на Win10

Нужен ToolChain: препроцессор (cpp), компилятор ASM(as), компилятор С (gcc),компилятор С++(g++), компоновщик(ld), отладчик(gdb). Нужны binutils(ы) для диагностики полученных артефактов(nm, size, readelf), архиватор статических библиотек(ar), и прочее. Это основные утилиты, которые и делают всю работу по превращению исходников (*.с, *.h) в артефакты (*.hex *.bin *.map *.elf *.out файлики).

ToolChain следует брать с официального сайта

https://developer.arm.com/downloads/-/gnu-rm#:~:text=The%20GNU%20Arm%20Embedded%20Toolchain,Arm%20Cortex%2DR%20processor%20families

.

Toolchain устанавливается как обычная win программа прямо из gcc-arm-none-eabi-10.3-2021.10-win32.exe файла

Проверка, что установилось. Вот полный комплект GCC ARM. Всего 32 утилиты.

Как же make файл узнает, что нужен именно этот toolchain? Ведь их может быть установлено несколько в разные папки. Ответ прост. Надо прописать адрес toolchain в переменной Path. А старый путь просто дропнуть.

и тут

Каждый свой шаг надо проверять. Как проверить, что терминал cmd находит ToolChain? Откройте cmd из любой папки и наберите arm-none-eabi-gcc.exe –v

Версия должна отобразиться в соответствии с версией скаченного дистрибутива. ToolChain может находится примерно по такому адресу:

C:\Program Files (x86)\GNU ARM Embedded Toolchain\10 2021.10\bin\

Фаза 3. Установка Windows Build Tools binaries (Make, cp, rm, echo, sh…)

Самый классический способ сборки программ на С(ях) это, конечно же, Make файлы. Не перестаю удивляться насколько элегантна сборка программ из make. В 1970е года когда появились утилита make программировали только настоящие ученые со степенями докторов наук. Тогда у школоты как сейчас банально не было персональных компьютеров из-за дороговизны DeskTop(ов). В 197x программировали по настоящему достойные люди. Поэтому и появились такие утилиты-шедевры как make, grep, find, sort и прочее. Благодаря Make файлам  можно управлять модульностью сборок программных компонентов по-полной. Мгновенно, одной строчкой включать и исключать сотни файлов одновременно для сотен сборок. Это даже не снилось таким GUI(ням) как IAR с Keil, где приходится протирать дыры в коврике для мышки, чтобы сделать то, что в make делается одной строчкой в *.mk файлике.

Сейчас среди российских программистов микроконтроллеров make файлами умеет пользоваться в лучшем случае один из шести. Остальные не могут слезть с иглы GUI-IDE. Сборка прошивок из make это считается высшим пилотаже программирования на С(ях).

Вот минимальный набор утилит для процессинга Make файлов.

Утилита

Назначение

make

build automation tool

sh

Unix shell interpreter

busybox

a software suite that provides several Unix utilities

echo

Echo the STRING(s) to standard output.

cp

Copy SOURCEs to DEST

mkdir

Create DIRECTORY

rm

Remove (unlink) FILEs

Где же мне взять универсальный Makefile для сборки много-файловых проектов? Самое простое это воспользоваться код-генератором STM32CubeMX и сгенерировать MakeFile проект.

Далее аккуратно раздербанить его под общую кодовую базу. Получается вот такой файл с правилами.

mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
$(info Build  $(mkfile_path) )

BUILD_DIR = build

#@echo $(error SOURCES_C= $(SOURCES_C))
INCDIR := $(subst /cygdrive/c/,C:/, $(INCDIR))
#@echo $(error INCDIR=$(INCDIR))
SOURCES_C := $(subst /cygdrive/c/,C:/, $(SOURCES_C))
#@echo $(error SOURCES_C=$(SOURCES_C))
SOURCES_ASM := $(subst /cygdrive/c/,C:/, $(SOURCES_ASM))
LDSCRIPT := $(subst /cygdrive/c/,C:/, $(LDSCRIPT))
#@echo $(error SOURCES_ASM=$(SOURCES_ASM))

# binaries
PREFIX = arm-none-eabi-
# The gcc compiler bin path can be either defined in make command via GCC_PATH variable (> make GCC_PATH=xxx)
# either it can be added to the PATH environment variable.
ifdef GCC_PATH
  CC = $(GCC_PATH)/$(PREFIX)gcc
  AS = $(GCC_PATH)/$(PREFIX)gcc -x assembler-with-cpp
  CP = $(GCC_PATH)/$(PREFIX)objcopy
  SZ = $(GCC_PATH)/$(PREFIX)size
else
  CC = $(PREFIX)gcc
  AS = $(PREFIX)gcc -x assembler-with-cpp
  CP = $(PREFIX)objcopy
  SZ = $(PREFIX)size
endif
HEX = $(CP) -O ihex
BIN = $(CP) -O binary -S
 
# CFLAGS
#https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
FPU = 
FPU += -mfpu=fpv4-sp-d16

FLOAT-ABI = -mfloat-abi=hard

MCU = $(CPU) -mthumb $(FPU) $(FLOAT-ABI)

CSTANDARD = -std=c11

AS_DEFS = 

AS_INCLUDES = 
OPT += -Os
    
ifeq ($(DEBUG), Y)
    #@echo $(error DEBUG=$(DEBUG))
    CFLAGS += -g3 -gdwarf-2 -ggdb
endif

ASFLAGS = $(MCU) $(AS_DEFS) $(AS_INCLUDES) $(OPT) -Wall -fdata-sections -ffunction-sections

CFLAGS += $(MCU) $(OPT) $(INCDIR) -Wall -fdata-sections -ffunction-sections $(CSTANDARD)


# Generate dependency information
CFLAGS += -MMD -MP -MF"$(@:%.o=%.d)"

# LDFLAGS

# libraries
LINKER_FLAGS += -Xlinker --gc-sections 
ifeq ($(MBR), Y)
    #@echo $(error MBR=$(MBR))
    LIBS += -lnosys
else
    LIBS += -lnosys 
    LINKER_FLAGS += -u _scanf_float
    LINKER_FLAGS += -u _printf_float
endif

ifeq ($(LIBC), Y)
    #@echo $(error LIBC=$(LIBC))
    LIBS += -lc
endif

ifeq ($(MATH), Y)
    #@echo $(error MATH=$(MATH))
    LIBS += -lm 
endif


#@echo $(error LDSCRIPT=$(LDSCRIPT))
LIBDIR = 

LDFLAGS += $(MCU) -specs=nano.specs -T$(LDSCRIPT) $(LIBDIR) $(LIBS) -Wl,-Map=$(BUILD_DIR)/$(TARGET).map,--cref -Wl,--gc-sections $(LINKER_FLAGS)

# default action: build all
all: $(BUILD_DIR)/$(TARGET).elf $(BUILD_DIR)/$(TARGET).hex $(BUILD_DIR)/$(TARGET).bin


# build the application
# list of objects
OBJECTS = $(addprefix $(BUILD_DIR)/,$(notdir $(SOURCES_C:.c=.o)))
vpath %.c $(sort $(dir $(SOURCES_C)))
# list of ASM program objects
OBJECTS += $(addprefix $(BUILD_DIR)/,$(notdir $(SOURCES_ASM:.S=.o)))
vpath %.S $(sort $(dir $(SOURCES_ASM)))

$(BUILD_DIR)/%.o: %.c Makefile | $(BUILD_DIR) 
	$(CC) -c $(CFLAGS) -Wa,-a,-ad,-alms=$(BUILD_DIR)/$(notdir $(<:.c=.lst)) $< -o $@

$(BUILD_DIR)/%.o: %.S Makefile | $(BUILD_DIR)
	$(AS) -c $(CFLAGS) $< -o $@

$(BUILD_DIR)/$(TARGET).elf: $(OBJECTS) Makefile
	$(CC) $(OBJECTS) $(LDFLAGS) -o $@
	$(SZ) $@

$(BUILD_DIR)/%.hex: $(BUILD_DIR)/%.elf | $(BUILD_DIR)
	$(HEX) $< $@
	
$(BUILD_DIR)/%.bin: $(BUILD_DIR)/%.elf | $(BUILD_DIR)
	$(BIN) $< $@	
	
$(BUILD_DIR):
	mkdir $@		

# clean up
clean:
	-rm -fR $(BUILD_DIR)
  
# dependencies
-include $(wildcard $(BUILD_DIR)/*.d)

# *** EOF ***

Вот так выглядит пример make файла для компонента независимого сторожевого таймера

$(info IWDG_MK_INC=$(IWDG_MK_INC) )
ifneq ($(IWDG_MK_INC),Y)
    IWDG_MK_INC=Y
    
    mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
    $(info Build  $(mkfile_path) )
    
    IWDG_DIR = $(WORKSPACE_LOC)bsp/bsp_stm32f4/iwdg
    #@echo $(error IWDG_DIR=$(IWDG_DIR))
    IWDG=Y
    INCDIR += -I$(IWDG_DIR)
    OPT += -DHAS_IWDG

    SOURCES_C += $(IWDG_DIR)/iwdg_drv.c

    ifeq ($(CLI),Y)
        ifeq ($(IWDG_COMMANDS),Y)
            OPT += -DHAS_IWDG_COMMANDS
            SOURCES_C += $(IWDG_DIR)/iwdg_commands.c
        endif
    endif
endif

А это MakeFile для конкретной сборки.

MK_PATH:=$(dir $(realpath $(lastword $(MAKEFILE_LIST))))
#@echo $(error MK_PATH=$(MK_PATH))
WORKSPACE_LOC:= $(MK_PATH)../../
INCDIR += -I$(MK_PATH)
INCDIR += -I$(WORKSPACE_LOC)

include $(MK_PATH)components.mk
include $(MK_PATH)cli_config.mk
include $(MK_PATH)diag_config.mk
include $(MK_PATH)test_config.mk
include $(WORKSPACE_LOC)code_base.mk
include $(WORKSPACE_LOC)rules.mk

В Makefile тоже можно делать Include guard подобно *.h файлам препроцессора.

$(info FILE_MK_INC=$(FILE_MK_INC))
ifneq ($(FILE_MK_INC),Y)
    FILE_MK_INC=Y
endif

И так далее. Для каждой сборки один Makefile и множество общих *.mk файлов.

Windows Build Tools binaries можно скачать по ссылке.

Можно скопировать утилиты Windows Build Tools  в папку:

C:\xpack-windows-build-tools-4.3.0-1\bin

Фаза 4. Подключить настройки компоновщика (Linker(а)). (*.ld файл)

После сборки *.с файлов образуются столько же *.o фалов. Их надо скомпоновать в один *.bin файл. Этим занимается утилита arm-none-eabi-ld.exe. Как и любой утилите нужен свой конфигурационный файл. Обычно это *.ld файл. Вот пример конфигурации компоновщика для сборки первичного загрузчика.


/* Entry Point */
ENTRY(Reset_Handler)

/* Highest address of the user mode stack */
_estack = ORIGIN(RAM) + LENGTH(RAM);    /* end of RAM */
/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size  = 0x200; /* required amount of heap  */
_Min_Stack_Size = 0x900; /* required amount of stack */

/* Specify the memory areas */
MEMORY
{
RAM (xrw)  : ORIGIN = 0x20000000, LENGTH = 320K
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 16K
}

/* Define output sections */
SECTIONS
{
  /* The startup code goes first into FLASH */
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >FLASH

  /* The program code and other data goes into FLASH */
  .text :
  {
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.text*)          /* .text* sections (code) */
    *(.glue_7)         /* glue arm to thumb code */
    *(.glue_7t)        /* glue thumb to arm code */
    *(.eh_frame)

    KEEP (*(.init))
    KEEP (*(.fini))

    . = ALIGN(4);
    _etext = .;        /* define a global symbols at end of code */
  } >FLASH

  /* Constant data goes into FLASH */
  .rodata :
  {
    . = ALIGN(4);
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    . = ALIGN(4);
  } >FLASH

  .ARM.extab   : { *(.ARM.extab* .gnu.linkonce.armextab.*) } >FLASH
  .ARM : {
    __exidx_start = .;
    *(.ARM.exidx*)
    __exidx_end = .;
  } >FLASH

  .preinit_array     :
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array*))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  } >FLASH
  .init_array :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array*))
    PROVIDE_HIDDEN (__init_array_end = .);
  } >FLASH
  .fini_array :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array*))
    PROVIDE_HIDDEN (__fini_array_end = .);
  } >FLASH

  /* used by the startup to initialize data */
  _sidata = LOADADDR(.data);

  /* Initialized data sections goes into RAM, load LMA copy after code */
  .data : 
  {
    . = ALIGN(4);
    _sdata = .;        /* create a global symbol at data start */
    *(.data)           /* .data sections */
    *(.data*)          /* .data* sections */

    . = ALIGN(4);
    _edata = .;        /* define a global symbol at data end */
  } >RAM AT> FLASH

  
  /* Uninitialized data section */
  . = ALIGN(4);
  .bss :
  {
    /* This is used by the startup in order to initialize the .bss secion */
    _sbss = .;         /* define a global symbol at bss start */
    __bss_start__ = _sbss;
    *(.bss)
    *(.bss*)
    *(COMMON)

    . = ALIGN(4);
    _ebss = .;         /* define a global symbol at bss end */
    __bss_end__ = _ebss;
  } >RAM

  /* User_heap_stack section, used to check that there is enough RAM left */
  ._user_heap_stack :
  {
    . = ALIGN(4);
    PROVIDE ( end = . );
    PROVIDE ( _end = . );
    . = . + _Min_Heap_Size;
    . = . + _Min_Stack_Size;
    . = ALIGN(4);
  } >RAM

  /* Remove information from the standard libraries */
  /DISCARD/ :
  {
    libc.a ( * )
    libm.a ( * )
    libgcc.a ( * )
    libnosys.a ( * )
  }

  .ARM.attributes 0 : { *(.ARM.attributes) }
}

Фаза 5. Подключить инициализацию окружения. Ассемблерный код.

До запуска функции main() происходит множество инфраструктурных действий:

  1. Выбрать вариант загрузки по двум Boot пинам (Flash 0x0000_0000, Flash 0x0800_0000, SRAM 0x2000_0000)

  2. Проинициализировать регистр указателя SP на начало стека первым qWord(ом) бинаря.

  3. Проинициализировать глобальные переменные в RAM данными из бинаря. (интервал rwdata).

  4. Обнулить неинициализированные переменные в RAM (интервал bss).

  5. Настроить ядро вычисление с плавающей точкой FPU.

  6. Прописать в регистры процессора местонахождение адресов обработчиков прерываний.

  7. Примонтировать, если нужно, внешнюю Off-Chip RAM память.

Всё это прописано в коде на Assembler в *.S файле. Который отрабатывает до запуска функции main(). Это например файл startup_stm32f413xx.S

Фаза 6. Нужны сорцы от Vendor(ов) чипа.

Чтобы можно было начать разрабатывать какое-то приложение и бизнес логику нужно целая куча системного софта. Это базовый софт или System Software. В его состав входит всяческая инициализация. Инициализация тактирования(TIM, RCC, RTC), интерфейсов (CAN, SPI, I2S, I2C, UART, USB, GPIO, SDIO, SAI, Ethernet), системных компонент (FLASH, SRAM, DMA, MPU, IWDG, RNG, FPU, NVIC), возможностей генерации (DAC, PWM). Это десятки тысяч строк кода. К счастью часть этого кода предоставляют нормальные вендоры чипов.

При разработке на STM32 у нас по сути два вендора: Компания ARM и Компания STMicroelectronic.

Компания ARM выпускает так называемый CMSIS(Common Microcontroller Software Interface Standard). Это С обертки для ASM команд под Cortex-M чипы. Так же *.ld файлики для компоновщика. Это скачивается с их сайта https://silver.arm.com/browse/CMSIS после регистрации

Компания STMicroelectonic выкатывает HAL Drivers — базовый системный софт для инициализации периферии микроконтроллера. Самое простое это установить их компанейский код генератор и STM32CubeMX по ссылке и сгенерировать проект.

STM32CubeMX сам скачает и сохранит сорцы базового кода в папку STM32F4xx_HAL_Driver. Только скачивать предстоит через Tor browser так как РФ у ST числится санкционной территорией. Вот список сорцов STM32F4xx_HAL_Driver от вендора:

Обратите внимание никаких статических библиотек (*.а) как у Texas Instruments. Чистые сорцы (*.c *.h файлики).

Фаза 7. Как скормить прошивку микроконтроллеру? 

Накатить прошивку на чип можно при помощи программатора ST-Link через интерфейс SWD/JTAG и утилиты STM32 ST-LINK Utility.exe. Программатор может быть встроен в отладочную плату от ST, как например в семействе Nucleo_f4XXXxx:

Если вы записываете Generic *.bin артефакт(приложение), то надо указать адрес начала бинарная в On-Chip Nor Flash памяти. Запись *.hex файлов безопаснее так как вам не надо явно указывать адрес начала прошивки. Прошивка это просто бинарный массив в файле. Текстовым редактором его не проанализируешь. Анализировать содержимое бинарных файлов (*.bin) можно консольной утилитой-переходником hexdump.exe. Даешь *.bin получаешь Hex Wall в *.txt

hexdump -C nucleo_f401re_gcc_m.bin > nucleo_f401re_gcc_m.txt

Стоит убедиться, что в первом qword всегда адрес из RAM (начало стека), а во втором qword всегда адрес из Flash (Reset_Handler).  Тогда прошивка не зависнет до запуска main().

GUI окно утилиты STM32 ST-LINK Utility.exe. Можно прописать прошивку по любому отступу.

Классическая ситуация: накатили прошивку и плата зависла. Не  мигает heartbeat LED. Как вариант может помочь пошаговая отладка.

Для пошаговой отладки потребуется обновление прошивки программатора ST-Link. Это можно выполнить прямо в утилите STM32 ST-LINK Utility.exe во вкладке ST-LINK:

С точки зрения DevOps(а) надо прошивать чипы из командной строки, Batch скриптом. Это легко автоматизировать. Вот скрипт автоматического обновления прошивки при помощи утилиты ST-LINK_CLI.exe

echo off
cls

set project_name=nucleo_f413zh_generic_gcc_d_m
set project_dir=%cd%
echo project_dir=%project_dir%
set artefact_hex=%project_dir%\build\%project_name%.hex
set FlashTool="C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility\ST-LINK_CLI.exe"
rem set Device= ID=0x463 SN=066CFF323535474B43013113 
set Device= 
set options= -c %Device% SWD freq=4000 HOTPLUG  LPM -P %artefact_hex% -V "after_programming" -Log -TVolt
call %FlashTool% %options%
rem Reset System
call %FlashTool% -Rst

 

Вот лог результата работы

Easy!
Прошивка из ST-LINK_CLI.exe эффективнее, поскольку использует драгоценный интерфейс USB-SWD, только тогда, когда это реально нужно, а не всегда как в GUI версия (STM32 ST-LINK Utility.exe).

Фаза 8. Установка Debug Server

Для пошаговой отладки надо установить GDB Server. Это утилита-переходник, которая с одной стороны допрашивает чип по SWD или JTAG, а с другой стороны обслуживает TCP сокет к которому подключится отладчик arm-none-eabi-gdb.exe к порту с номером 61234. 

Эту утилиту можно извлечь из набора утилит от Atollic TrueSTUDIO. Atollic TrueSTUDIO(R) for STM32 можно скачать с сайта ST.com.

 Надо зарегистрироваться на сайте st.com. Скачивать дистрибутив en.TrueSTUDIO_V9.3.exe.exe получится при помощи Tor Browser так как РФ у ST числится, как санкционная территория.

ST-LINK_gdbserver установлен в 

C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.3.0\Servers\ST-LINK_gdbserver\ST-LINK_gdbserver.exe

Нужно добавить в переменную Path путь к папке с утилитами binutils компилятора. В данном случае этот путь выглядит так:

C:\Program Files (x86)\GNU Tools ARM Embedded\5.4 2016q3\bin\

Опционально можно настроить конфигурацию отладчика в текстовом редакторе Eclipse во вкладке Run->External Tools->External Tools Configurations… или просто запустить GDB server (сервер отладки) вручную. Перейти в папку:

C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.3.0\Servers\ST-LINK_gdbserver

запустить скрипт  ST-LINK_gdbserver.bat.

C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.3.0\Servers\ST-LINK_gdbserver\ST-LINK_gdbserver.bat

Путь к отладочному серверу C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility следует прописать в переменную Path

Фаза 9. Настройка Debug конфигурации для конкретной сборки

Неудобство Eclipse по сравнению с тем же пресловутым IAR это то, что для каждой сборки приходится настраивать конфигурацию отладки. Однако в Eclipse можно нажать Ctrl+3 появится окно быстрого поиска

и набрать там Debug Configuration. Надо прописать путь к *.elf файлу.

На вкладке Debugger надо прописать путь к отладчику от ARM GCC

C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin\arm-none-eabi-gdb.exe

и прописать порт от сервера отладки localhost:61234

На вкладке Startup надо прописать, что следует поставить точку останова на функции main(). Можно поставить точку останова также на более ранних функциях Reset_Handler или SystemInit().

Перед началом пошаговой отладки надо запустить отладочный сервер . Достаточно просто запустить на исполнение скрипт ST-LINK_gdbserver.bat в папке 

C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.3.0\Servers\ST-LINK_gdbserver

Желательно из-под командной строки cmd, чтобы были видны логи отладочного сервера.

Для того чтобы выполнять пошаговую отладку нужно пересобрать артефакты с опциями компилятора

-g3 -gdwarf-2 -ggdb

Пошаговая отладка подсвечивается прямо в текстовом редакторе Eclipse зеленой строчкой. Это благодаря утилите arm-none-eabi-addr2line.exe. Текстовый редактор Eclipse сам парсит вывод addr2line и подсвечивает активный адрес в виде зелёной строчки в коде.

Во время пошаговой отладки светодиоды программатора ST-Link должны мигать зелено-красным цветом.

Блок-схема Toolchain(а)

Все вышесказанное можно представить в виде одной блок-схемы (Helicopter view) на одном единственном листочке. Такова общая канва.

Для нас исходниками являются файлы с расширениями *.ld, *.c, *.h, *.S, *.cproject, *.project, *.Makefile, *.mk , *.bat — их и надо подвергать версионному контролю в GIT.   Автогенеренными для нас являются файлы с расширениями *.o, *.bin, *.bak, *.hex, *.map, *.elf, *.out, *.d, *.a. Отгружать следует файлы *.bin, *.hex, *.map, *.elf. Это артефакты или конечный продукт работы программиста микроконтроллера. 

Также рекомендую пользоваться GIТ(ом) исключительно

из-под командной строки

. Так вы сможете обрабатывать вывод утилиты git легендарное утилитой grep. Можно делать вложенные grep поверх grep. Вот например так.

Если бы был аналог утилиты grep в материальном мире, то вы бы могли находить иголки в стоге сена, понимаете? Вам уже нравится утилита grep?

UART CLI Для отладки (или добавьте в прошивку гласность) 

Любая разработка начинается там, где есть возможность наблюдать за тем, что получилось после изменений. Поэтому вам понадобится интерфейс командной строки CLI для отладки софта и железа. Крайне желательно использовать раскраску логов, чтобы концентрировать внимание на ошибках (красный) и предупреждениях (желтый). Плюс появление цвета в консоли это признак того, что поток символов непрерывный так как коды цветов распарсились корректно. Своего рода контрольная сумма принятых данных. Да и вообще консольные логи должны выглядеть весело. Просматривать UART-CLI логи можно в утилите TeraTerm или PuTTY. Они точно понимают символы цветов.

Поэтому надо активировать свободный UART, написать в прошивке интерпретатор команд CLI для RunTime отладки по интерфейсу UART. CLI(шку) можно также инкапсулировать в любой полу или полнодуплексный интерфейс(LoRa, CAN, UART, RS485) или протокол (TCP/UDP). При наличии CLI для общения с гаджетом вам не нужно будет писать никакую GUI(ню) на QT, .Net или Python. Достаточно только общедоступных терминалов Serial порта как TeraTerm, PyTTY, Hercules. Это же успех!

Трюки для эффективной отладки прошивок

  • Всегда проверяйте адрес функции main(). Может случится, что техник записал Generiс *.bin в область памяти для Bootloader или наоборот. Прошивка должна проверять адрес функции main, что он лежит в нужном секторе On-Chip NorFlash(а).

  • Используйте файловую систему FlashFs. Это позволит уменьшить количество сборок, так как конфигурации будут в файловой системе.

  • Используйте HeartBeat LED. Так вы поймете, что прошивка зависла, если нет мигания.

  • Используйте GPIO+Oscilloscope+DMM для физической отладки быстрых процессов.

  • Разделяйте аппаратно-зависимый и аппаратно-независимый код. Аппаратно-независимый код тестируйте на LapTop(е).

  • Используйте серверы сборки (например Jenkins) для поддержания на плаву своих сборок. У вас всегда будет готовый артефакт для отгрузки. Плюс сразу будет видно какие сборки конфликтуют и оперативно принять меры по улучшению модульности.

  • Пишите свои загрузчики. Программатор может исчезнуть, сломаться. С загрузчиком вы обновите прошивку своего гаджета буквально по 3м проводам UART. Причем делайте первичный и вторичный загрузчик. Это позволит прописывать вторичный загрузчик по произвольному адресу.

  • Используйте интерфейс SWD/JTAG для пошаговой отладки и поиска причин зависаний.

  • Используйте утилиту STM Studio для построения графиков переменных по их адресу в ячейках RAM.

  • Покрывайте код модульными тестами (программные скрепы). Это лучший способ найти ошибку в коде, который затруднительно пройти пошаговой отладкой. Плюс тесты помогут безопасно делать перестройку (рефакторинг). Сегодня российское общество испытывает явный дефицит программных скреп.

Вывод

Существуют и другие ToolChain(ы) (IAR, Keil). Тут же я написал про бесплатный способ полноценно вести разработку и отладку на STM32. Однако если разработчик научится собирать код из make, то он перестанете быть рабом IDE с их периодическими зависаниями. Плюс можно сэкономить 3500 EUR не покупая проприетарный компилятор, который еще и не продадут из-за санкций.

Ссылки на похожие посты:

STM32 + CMSIS + STM32CubeIDE

ARM-ы для самых маленьких: тонкости компиляции и компоновщик

STM32 на MAC OS

Отладка STM32 в среде Eclipse+GCC

ARM-ы для самых маленьких: компоновка-2, прерывания и hello world!

STM32 + CMSIS + STM32CubeIDE

ARM-микроконтроллеры STM32F. Быстрый старт c STM32-Discovery

Развертывание среды разработки для STM32

STM32CubeMX — продвинутый генератор проектов для STM32

Eclipse для микроконтроллеров (STM32) + FreeRTOS Task Aware Debugge

Переход из online в offline IDE при программировании Nucleo-F401RE

Начинаем изучать Cortex-M на примере STM32

Программируем микроконтроллеры stm32 при помощи QtCreator

Настраиваем бесплатную сборку для написания и отладки программ под микроконтроллеры на основе ядра ARM под Windows 10

Tutorial: Makefile Projects with Eclipse

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы собираете артефакты прошивок из Make файлов?

Проголосовали 44 пользователя. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы пользуйтесь текстовым редактором Eclipse?

Проголосовали 49 пользователей. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы собираете артефакты для МК компилятором GCC?

Проголосовали 46 пользователей. Воздержались 6 пользователей.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы собираете прошивки в Windows?

Проголосовали 50 пользователей. Воздержались 4 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы собираете артефакты прошивок из СMake файлов?

Проголосовали 47 пользователей. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы собираете прошивки из IDE IAR?

Проголосовали 49 пользователей. Воздержались 2 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы пользуйтесь пошаговой отладкой прошивок?

Проголосовали 50 пользователей. Воздержались 2 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы пользуйтесь отладкой прошивок через интерфейс командной строки?

Проголосовали 46 пользователей. Воздержались 4 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы пользуйтесь сервером сборки (например Jenkins) для автоматической сборки артефактов?

Проголосовали 47 пользователей. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы покрываете код прошивок модульными тестами?

Проголосовали 45 пользователей. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы пользуйтесь системой контроля версий GIT?

Проголосовал 51 пользователь. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Этот текст нанёс вам пользу?

Проголосовали 19 пользователей. Воздержались 5 пользователей.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы обнаружили в тексте 3 пасхалки?

Проголосовали 15 пользователей. Воздержались 3 пользователя.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы пользуйтесь утилитой grep?

Проголосовали 19 пользователей. Воздержался 1 пользователь.

Download project files

How do I verify a
download?

1


10

of
18
releases

First

Previous

Next


Last

5-2016-q3-update release
from the
5.0 series released

File Description Downloads
release.txt (md5) Release notes

17,880


last downloaded


2 days
ago

gcc-arm-none-eabi-5_4-2016q3-20160926-win32.exe (md5) Windows installer

715,179


last downloaded

today

gcc-arm-none-eabi-5_4-2016q3-20160926-win32.zip (md5) Windows zip package

330,660


last downloaded


24 hours
ago

gcc-arm-none-eabi-5_4-2016q3-20160926-linux.tar.bz2 (md5) Linux installation tarball

582,615


last downloaded


24 hours
ago

gcc-arm-none-eabi-5_4-2016q3-20160926-mac.tar.bz2 (md5) Mac installation tarball

158,917


last downloaded


24 hours
ago

gcc-arm-none-eabi-5_4-2016q3-20160926-src.tar.bz2 (md5) Source package

133,234


last downloaded


24 hours
ago

How-to-build-toolchain.pdf (md5) How to build

64,144


last downloaded


24 hours
ago

readme.txt (md5) README

81,977


last downloaded


2 days
ago

license.txt (md5) Licenses

41,234


last downloaded


9 days
ago

Total downloads: 2,125,840

5-2016-q2-update release
from the
5.0 series released

Release information

Release notes:

The 5 2016q2 update release is available at:
——-——-——-——-——-——-——-——-——-

* https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q2-update
* https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa

Important bugs fixed in 5 update 2 release:
——-——-——-——-——-——-——-——-——-

* Fixed code-size regression for Cortex-M0 compared to 4.9 when compiling with -Os
* Fix multilib used for armv8-m.main+dsp
* Fix use of —gc-sections when building for ARMv8-M with Security Extensions
* Fix memcpy used for newlib-nano for pre ARMv6T2 devices
* Fix alignment of .data in ldscripts in samples
* Fix semihosting for ARMv7-A and ARMv7-R

Note
———

* Further releases will be available at https://developer.arm.com/open-sourc…

Changelog:

New Features
——-——-——-

* Re-tied the MALLOC_LOCK and MALLOC_UNLOCK to newlib’s multithread configuration for newlib-nano.

Important bugs fixed in 5 update 2 release
——-——-——-——-——-——-——-——-——-

* Fixed code-size regression for Cortex-M0 compared to 4.9 when compiling with -Os
* Fix multilib used for armv8-m.main+dsp
* Fix use of —gc-sections when building for ARMv8-M with Security Extensions
* Fix memcpy used for newlib-nano for pre ARMv6T2 devices
* Fix alignment of .data in ldscripts in samples
* Fix semihosting for ARMv7-A and ARMv7-R

Known Changes and Issues
——-——-——-——-——-——

* Thumb1 code size regression due to new register allocation:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
  *A workaround is to disable it by option -mno-lra*.
* The use of 64-bit atomic operations for ARMv8-M Mainline is not supported.

File Description Downloads
release.txt (md5) Release notes

4,341


last downloaded


3 weeks
ago

gcc-arm-none-eabi-5_4-2016q2-20160622-win32.exe (md5) Windows installer

178,028


last downloaded


24 hours
ago

gcc-arm-none-eabi-5_4-2016q2-20160622-win32.zip (md5) Windows zip package

200,653


last downloaded


24 hours
ago

gcc-arm-none-eabi-5_4-2016q2-20160622-linux.tar.bz2 (md5) Linux installation tarball

422,298


last downloaded

today

gcc-arm-none-eabi-5_4-2016q2-20160622-mac.tar.bz2 (md5) Mac installation tarball

90,836


last downloaded

today

gcc-arm-none-eabi-5_4-2016q2-20160622-src.tar.bz2 (md5) Source package

61,766


last downloaded


12 weeks
ago

How-to-build-toolchain.pdf (md5) How to build

9,669


last downloaded


6 days
ago

readme.txt (md5) README

9,431


last downloaded


24 hours
ago

license.txt (md5) Licenses

1,885


last downloaded


3 weeks
ago

Total downloads: 978,907

5-2016-q1-update release
from the
5.0 series released

File Description Downloads
release.txt (md5) Release notes

4,310


last downloaded


9 weeks
ago

gcc-arm-none-eabi-5_3-2016q1-20160330-win32.exe (md5) Windows installer

125,460


last downloaded


2 days
ago

gcc-arm-none-eabi-5_3-2016q1-20160330-win32.zip (md5) Windows zip package

84,377


last downloaded


24 hours
ago

gcc-arm-none-eabi-5_3-2016q1-20160330-linux.tar.bz2 (md5) Linux installation tarball

91,424


last downloaded


24 hours
ago

gcc-arm-none-eabi-5_3-2016q1-20160330-mac.tar.bz2 (md5) Mac installation tarball

59,550


last downloaded


24 hours
ago

gcc-arm-none-eabi-5_3-2016q1-20160330-src.tar.bz2 (md5) Source package

19,792


last downloaded


4 days
ago

How-to-build-toolchain.pdf (md5) How to build

11,080


last downloaded


4 days
ago

readme.txt (md5) README

10,149


last downloaded


8 weeks
ago

license.txt (md5) Licenses

1,348


last downloaded


9 weeks
ago

Total downloads: 407,490

5-2015-q4-major release
from the
5.0 series released

File Description Downloads
release.txt (md5) Release notes

5,480


last downloaded


2 weeks
ago

gcc-arm-none-eabi-5_2-2015q4-20151219-win32.exe (md5) Windows installer

153,143


last downloaded


4 days
ago

gcc-arm-none-eabi-5_2-2015q4-20151219-win32.zip (md5) Windows zip package

183,481


last downloaded

today

gcc-arm-none-eabi-5_2-2015q4-20151219-linux.tar.bz2 (md5) Linux installation tarball

183,027


last downloaded


24 hours
ago

gcc-arm-none-eabi-5_2-2015q4-20151219-mac.tar.bz2 (md5) Mac installation tarball

37,051


last downloaded


24 hours
ago

gcc-arm-none-eabi-5_2-2015q4-20151219-src.tar.bz2 (md5) Source package

74,983


last downloaded


4 days
ago

How-to-build-toolchain.pdf (md5) How to build

10,831


last downloaded


4 days
ago

readme.txt (md5) README

7,711


last downloaded


5 weeks
ago

license.txt (md5) Licenses

1,575


last downloaded


2 weeks
ago

Total downloads: 657,282

4.9-2015-q3-update release
from the
4.9 series released

Release information

Release notes:

Release notes for
*************************************************
GNU Tools for ARM Embedded Processors 4.9
                               — Q3 2015
*************************************************

This release includes the following items:
* Bare metal EABI pre-built binaries for running on a Windows host
* Bare metal EABI pre-built binaries for running on a Linux host
* Bare metal EABI pre-built binaries for running on a Mac OS X host
* Source code package (together with build scripts and instructions to setup
  build environment), composed of:
  * gcc : ARM/embedded-4_9-branch revision 227977
    http://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_9-branch/

  * binutils : 2.24 with mainline backports
    git://sourceware.org/git/binutils-gdb.git commit 136a940ac535e464d2a7a86880c...

File Description Downloads
release.txt (md5) Release notes

6,620


last downloaded


7 days
ago

gcc-arm-none-eabi-4_9-2015q3-20150921-win32.exe (md5) Windows installer

353,831


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_9-2015q3-20150921-win32.zip (md5) Windows zip package

145,202


last downloaded

today

gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 (md5) Linux installation tarball

3,867,022


last downloaded

today

gcc-arm-none-eabi-4_9-2015q3-20150921-mac.tar.bz2 (md5) Mac installation tarball

89,300


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_9-2015q3-20150921-src.tar.bz2 (md5) Source package

51,621


last downloaded


10 days
ago

How-to-build-toolchain.pdf (md5) How to build

18,251


last downloaded


2 days
ago

readme.txt (md5) README

466,043


last downloaded


8 days
ago

license.txt (md5) Licenses

3,384


last downloaded


7 days
ago

Total downloads: 5,001,274

4.9-2015-q2-update release
from the
4.9 series released

Release information

Release notes:

Release notes for
*************************************************
GNU Tools for ARM Embedded Processors 4.9
                               — Q2 2015
*************************************************

This release includes the following items:
* Bare metal EABI pre-built binaries for running on a Windows host
* Bare metal EABI pre-built binaries for running on a Linux host
* Bare metal EABI pre-built binaries for running on a Mac OS X host
* Source code package (together with build scripts and instructions to setup
  build environment), composed of:
  * gcc : ARM/embedded-4_9-branch revision 224288
    http://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_9-branch/

  * binutils : 2.24 with mainline backports
    git://sourceware.org/git/binutils-gdb.git commit 136a940ac535e464d2a7a86880c...

File Description Downloads
release.txt (md5) Release notes

4,383


last downloaded


4 weeks
ago

gcc-arm-none-eabi-4_9-2015q2-20150609-win32.exe (md5) Windows installer

143,851


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_9-2015q2-20150609-win32.zip (md5) Windows zip package

171,809


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_9-2015q2-20150609-linux.tar.bz2 (md5) Linux installation tarball

523,667


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_9-2015q2-20150609-mac.tar.bz2 (md5) Mac installation tarball

29,678


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_9-2015q2-20150609-src.tar.bz2 (md5) Source package

39,106


last downloaded


24 hours
ago

How-to-build-toolchain.pdf (md5) How to build

10,156


last downloaded


24 hours
ago

readme.txt (md5) README

7,957


last downloaded


4 weeks
ago

license.txt (md5) Licenses

1,382


last downloaded


3 weeks
ago

Total downloads: 931,989

4.9-2015-q1-update release
from the
4.9 series released

Release information

Release notes:

Release notes for
*************************************************
GNU Tools for ARM Embedded Processors 4.9
                               — Q1 2015
*************************************************

This release includes the following items:
* Bare metal EABI pre-built binaries for running on a Windows host
* Bare metal EABI pre-built binaries for running on a Linux host
* Bare metal EABI pre-built binaries for running on a Mac OS X host
* Source code package (together with build scripts and instructions to setup
  build environment), composed of:
  * gcc : ARM/embedded-4_9-branch revision 221220
    http://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_9-branch/

  * binutils : 2.24 with mainline backports
    git://sourceware.org/git/binutils.git commit 136a940ac535e464d2a7a86880ce1f1…

File Description Downloads
release.txt (md5) Release notes

4,693


last downloaded


7 weeks
ago

gcc-arm-none-eabi-4_9-2015q1-20150306-win32.exe (md5) Windows installer

161,537


last downloaded

today

gcc-arm-none-eabi-4_9-2015q1-20150306-win32.zip (md5) Windows zip package

103,495


last downloaded

today

gcc-arm-none-eabi-4_9-2015q1-20150306-linux.tar.bz2 (md5) Linux installation tarball

86,279


last downloaded

today

gcc-arm-none-eabi-4_9-2015q1-20150306-mac.tar.bz2 (md5) Mac installation tarball

23,436


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_9-2015q1-20150306-src.tar.bz2 (md5) Source package

20,639


last downloaded


9 weeks
ago

How-to-build-toolchain.pdf (md5) How to build

9,236


last downloaded


4 days
ago

readme.txt (md5) README

9,315


last downloaded


9 days
ago

license.txt (md5) Licenses

1,545


last downloaded


2 weeks
ago

Total downloads: 420,175

4.9-2014-q4-major release
from the
4.9 series released

Release information

Release notes:

Release notes for
*************************************************
GNU Tools for ARM Embedded Processors 4.9
                               — Q4 2014
*************************************************

This release includes the following items:
* Bare metal EABI pre-built binaries for running on a Windows host
* Bare metal EABI pre-built binaries for running on a Linux host
* Bare metal EABI pre-built binaries for running on a Mac OS X host
* Source code package (together with build scripts and instructions to setup
  build environment), composed of:
  * gcc : ARM/embedded-4_9-branch revision 218278
    http://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_9-branch/

  * binutils : 2.24 with mainline backports
    git://sourceware.org/git/binutils.git commit 136a940ac535e464d2a7a86880ce1f1…

File Description Downloads
release.txt (md5) Release notes

5,414


last downloaded


4 weeks
ago

gcc-arm-none-eabi-4_9-2014q4-20141203-win32.exe (md5) Windows installer

761,860


last downloaded


4 days
ago

gcc-arm-none-eabi-4_9-2014q4-20141203-win32.zip (md5) Windows zip package

230,832


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_9-2014q4-20141203-linux.tar.bz2 (md5) Linux installation tarball

169,874


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_9-2014q4-20141203-mac.tar.bz2 (md5) Mac installation tarball

18,953


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_9-2014q4-20141203-src.tar.bz2 (md5) Source package

77,560


last downloaded


4 days
ago

How-to-build-toolchain.pdf (md5) How to build

11,542


last downloaded


3 days
ago

readme.txt (md5) README

7,938


last downloaded


6 weeks
ago

license.txt (md5) Licenses

1,603


last downloaded


6 weeks
ago

Total downloads: 1,285,576

4.8-2014-q3-update release
from the
4.8 series released

Release information

Release notes:

Release notes for
*************************************************
GNU Tools for ARM Embedded Processors 4.8
                               — Q3 2014
*************************************************

This release includes the following items:
* Bare metal EABI pre-built binaries for running on a Windows host
* Bare metal EABI pre-built binaries for running on a Linux host
* Bare metal EABI pre-built binaries for running on a Mac OS X host
* Source code package (together with build scripts and instructions to setup
  build environment), composed of:
  * gcc : ARM/embedded-4_8-branch revision 213147 with cortex-m7 patches
    http://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_8-branch/

  * binutils : 2.23 with mainline backports and cortex-m7 patches
    git://sourceware.org/git/binuti...

File Description Downloads
release.txt (md5) Release notes

5,717


last downloaded


2 weeks
ago

gcc-arm-none-eabi-4_8-2014q3-20140805-win32.exe (md5) Windows installer

263,193


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_8-2014q3-20140805-win32.zip (md5) Windows zip package

238,496


last downloaded

today

gcc-arm-none-eabi-4_8-2014q3-20140805-linux.tar.bz2 (md5) Linux installation tarball

335,455


last downloaded

today

gcc-arm-none-eabi-4_8-2014q3-20140805-mac.tar.bz2 (md5) Mac installation tarball

28,244


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_8-2014q3-20140805-src.tar.bz2 (md5) Source package

40,660


last downloaded


5 days
ago

How-to-build-toolchain.pdf (md5) How to build

10,459


last downloaded


24 hours
ago

readme.txt (md5) README

13,741


last downloaded


24 hours
ago

license.txt (md5) Licenses

1,634


last downloaded


24 hours
ago

Total downloads: 937,599

4.8-2014-q2-update release
from the
4.8 series released

Release information

Release notes:

Release notes for
*************************************************
GNU Tools for ARM Embedded Processors 4.8
                               — Q2 2014
*************************************************

This release includes the following items:
* Bare metal EABI pre-built binaries for running on a Windows host
* Bare metal EABI pre-built binaries for running on a Linux host
* Bare metal EABI pre-built binaries for running on a Mac OS X host
* Source code package (together with build scripts and instructions to setup
  build environment), composed of:
  * gcc : ARM/embedded-4_8-branch revision 211358
    http://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_8-branch/

  * binutils : 2.23 with mainline backports
    git://sourceware.org/git/binutils.git commit 8ea85793ab9a147f826a2d30ff612d6…

File Description Downloads
release.txt (md5) Release notes

4,827


last downloaded


7 days
ago

gcc-arm-none-eabi-4_8-2014q2-20140609-win32.exe (md5) Windows installer

54,154


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_8-2014q2-20140609-win32.zip (md5) Windows zip package

59,757


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_8-2014q2-20140609-linux.tar.bz2 (md5) Linux installation tarball

90,380


last downloaded

today

gcc-arm-none-eabi-4_8-2014q2-20140609-mac.tar.bz2 (md5) Mac installation tarball

15,722


last downloaded


24 hours
ago

gcc-arm-none-eabi-4_8-2014q2-20140609-src.tar.bz2 (md5) Source package

19,877


last downloaded


4 weeks
ago

How-to-build-toolchain.pdf (md5) How to build

11,771


last downloaded


3 days
ago

readme.txt (md5) README

40,950


last downloaded


5 days
ago

license.txt (md5) Licenses

1,457


last downloaded


9 weeks
ago

Total downloads: 298,895

1


10

of
18
releases

First

Previous

Next


Last

Using a manufacturer independent tooling can have good impacts on autonomy, learning experience and realization on what really works for an engineer regarding the whole embedded development process. I wanted to look for a complete setup working natively in Windows, yet as much as possible open source, to have a manufacturer independent tooling.

I will try to present it in an article I wished to have available when I started, hopefully letting you avoid the process of cherry picking infos from different tutorials. I’ll address also the small quirks and issues I faced in order to have everything working smoothly and in a scalable way. And where relevant, links to a more complete resources are given.

So in this article I will walk you through:

  • Installing the necessary tools
  • Setting up an extremely minimal firmware for an STM32 ARM microcontroller
  • Debugging in Windows using native and updated software

Also I must aknowledge this article series from MCU On Eclipse that gave me a huge help in starting out the foundations to tailor the final solutions described in here.

First things first, install your tools

The tools selection is justified by using ideally the most supported solutions to achieve such a development setup. There are also quasi de facto standards are VSCode, CMake, Make, ARM GCC, and OpenOCD with the ARM GDB, so these will be the tools used in this article. Below are schematized our set of tools needed, going all the way down from source code to hardware!

So let’s begin!

The editor: VSCode

In this scenario we are going to use VSCode, hence the conventional installation holds with no problem as this is native on Windows. Download the binaries from the official website and after installing them, you are good to go.

Writing makefiles using CMake

To compose our makefile we are going to use the power of CMake. To install it correctly there should be no issues, as can be downloaded from their website.
Make just sure you’ll add CMake in the system path as following:

The advantage to use CMake, once is setup, is that is very scalable for different projects, and is ready for more modern alternatives to Make, like Ninja (not covered in this article).

The king compiler, ARM GCC

To install the main component of this setup, today ARM simplified a lot for us, providing an installer which include all the tools, including the GDB tools on top of all sort of tools and other compilers for different platforms. Normally Google is your friend, but for reference it can be found in here. Make sure do download the AArch32 bare-metal target (arm-none-eabi) for this example.

Also here, make sure to have it in the system path:

For reference, the environment variable set in this case is C:\Program Files (x86)\Arm GNU Toolchain arm-none-eabi\13.2 Rel1\bin, and versions or personal options on where to install might vary.

Finally reading the makefiles with Make

Now we have a compiler, an editor to write code and run commands, and a tool to build a makefile. We need now –the- tool capable to read such a makefile and correctly interface with the compiler. In the open source world, this tool is GNU Make (among others more moderns/faster, like Ninja).

The tricky thing in Windows is that since it is a native open source tool for Linux, gets compiled and installed from the official Linux based sources, while in Windows the habit is to download and install a pre-compiled binary. Therefore, since from my limited experience in application software, in Windows is trickier doing this with Linux based sources, a binary is provided by different package managers and/or more or less official sources, which already did the work for us. Here a list where and how you can get it. Obviously, you just need to follow one of these alternatives.

Alternative 1: Winget

It is the most official package manager since it is maintained by Microsoft itself. But you might not get the latest version. To install this package manager if not already present in your Windows edition, and to install Make, just follow the official page.

Alternative 2: Precompiled packages

The one available, are an official, but outdated GnuWin32 project, available here.
Also in this case the make path must be inserted in the environmental variables of Windows, inserting the installation path in “Path”:

Alternative 3: MinGW

This is the entire GCC environment ported on Windows, which includes obviously also Make. It can be taken from the Winlibs project. Follow the latest revision, i.e. “GCC 13.2.0 (with POSIX threads)“.

Here is just needed to unpack the content in our desired folder, i.e. “C:\gcc\13.2.0”. Then we must add our binaries to the Windows system path:

Alternative 4: Other package managers, Chocolatey

This is another famous and well maintaned package manager. With this you need to follow the first installation procedure listed here.

Then install make by running the Power Shell in admin mode, then type choco install make

Fun fact: in here the environment variables are not needed to be set, yet you might want to know that Chocolatey puts the binaries in C:\ProgramData\chocolatey\lib.

The final piece, OpenOCD

This is another of those tools available either from sources or from a bunch of package distributors. Here also I’ve found couple of alterntives.

Alternative 1: I’ve initially followed this guide from MCU On Eclipse, but it requires to install node.js and and the xpm package distributor, which I don’t find myself using too much. But the project is well maintained and can be used.

Alternative 2: Using Chocolatey again! After being sure is installed by follow the instructions listed before, just run choco install openocd with Power Shell in admin mode and you are set.

Development environment setup (hardware and software tools)

Finally! All is installed and we are ready to setup a VSCode based project. Let’s open VSCode and install the plugins needed to setup the debugging environment, we will create a new project called aleaengineering_arm_makefiles_article (at least this is how is called in the downloadable example).

The hardware

We are going to use the “BluePill”, an STM32F103C8T based development board. It will be coupled with a ST-Link programmer. An official one like the V2 can also be used and is the revision which this article was tested with. The V3 is actually the last one, but I personally didn’t test it. To be precise, in the article is used a clone of the V2, but given how inexpesinve programmers have become, personally won’t make sense to buy clones anymore.

So the connection is done via SWD, and with this particular board, each wire is accessible. For reference, we just need the Data IO and Data Clock, as shown in the picture above. Other boards, like Nucleo series (in my lab at the time of writing I currently do experiment with the NUCLEO-C031C6), have the STLink integrated with the SWD already connected:

To install the driver, and note this is debugger specific, for the STLink you either need a complete install of the STM32 Cube IDE, or you need to install the driver from the official website.

The IDE configuration

As IDE the base is obviously VSCode. On top of it, is essentially needed one plugin, or extention, the “Cortex-Debug” from the VScode marketplace. So after starting VSCode (non admin priviledges are ok for now), we just need to click on the left (Extentions) or ctrl + shift + x, then type “Marus” or any keyword that includes the name or description, and the extention shown below will appears:

This extention allows to write the .json scripts needed to have the capacity to flash and debug our target MCU, and manage all the debugging part of the project.

In general, for our needs and for importing a project like in this example, is to import a folder as a workspace, by simply open a new VSCode instance, then drag&drop the folder to it:

Finally, before proceeding, we must also use the integrated terminal to keep everything easily aligned:

External Windows or other terminals can be used, but here for simplicity it will be all done with the integrated one in VSCode.

Now, let’s start to configure the project.

Setting up .json files

In order to parse correctly the paths to use OpenOCD with the Cortex-Debug plugin and have the debug option appear in the VSCode environment, three .json files need to be written. These must be put in the .vscode folder, which I create for any new workspace and will be project specific, and it has to be the first folder in the hierarchy. For example, in VSCode, when opening a new folder, in this example you can open aleaengineering_arm_makefiles_article (sources downloadable at the end) and the .vscode folder is under it, as follow:

Writing the “settings.json”

This will be used to include the paths available to the Cortex-Debug plugin. Here will be set the path to the ARM GNU Debugger, the path to OpenOCD and eventually other debuggers one might want to use, for example the official ST-Link, here included as an alternative to make the example more complete showing that is possible to add any debugger. And it will be as follows:

{
    "cortex-debug.gdbPath": "C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/arm-none-eabi-gdb.exe",
    "cortex-debug.openocdPath": "C:/ProgramData/chocolatey/lib/openocd/tools/install/bin/openocd.exe",
    "cortex-debug.variableUseNaturalFormat": true,
    "cortex-debug.stlinkPath": "C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.1.0.202305091550/tools/bin/ST-LINK_gdbserver.exe"

}

Dont’t forget the “launch.json”

One of the most important part is to instruct the Cortex-Debug which parameter use with the tools located in the previously set folders. In this case we are going to set various modes of the OpenOCD/STLink we are going to use. For example, if launching, attaching, interface, device etc. For a complete list, the wiki from the developer of Cortex-Debug is a great start.

Here I have set the OpenOCD and STLink. So for example, the OpenOCD configuration will expand to:

  • Having the folder structure as in this example, the “${workspaceRoot}” will correctly point to our project files, hence “cwd”: “${workspaceRoot}” (today this is also replaceable with the “${workspaceFolder}” variable)
  • Request is launch, so it will flash the binaries before each debug action
  • For OpenOCD the servertype is self-explanatory
  • It will run to main before stopping for debug
  • Interface here is SWD, this is board/debugger dependent
  • In this example we will use an STM32F103C8T MCU
  • Config files are a must for OpenOCD as we must select the physical interface used (here stlink) and the target type (here stm32f1x)

Therefore the .json will look like:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "STlink launch DEBUG",
            "cwd": "${workspaceRoot}/Src",
            "executable": "${workspaceRoot}/build/Debug/AleaExample.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "stlink",
            "device": "STM32F103C8Tx",
            "showDevDebugOutput": "raw",
            "interface": "swd",
            "runToMain": true, // else it starts at reset handler - not interested
            // "preLaunchTask": "Build all", // configured in tasks.json
            // "preLaunchCommands": ["Build all"], // you can execute command instead of task
            "svdFile": "", // Include svd to watch device peripherals
            "swoConfig": {} // currently (v1.7.0) not supported
        },
        {
            "name": "openOCD launch DEBUG",
            "cwd": "${workspaceRoot}/Src",
            "executable": "${workspaceRoot}/build/Debug/AleaExample.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "runToEntryPoint": "main",
            "interface": "swd",
            "device": "STM32F103C8Tx",
            "showDevDebugOutput": "raw",
            "configFiles": [
                "C:/ProgramData/chocolatey/lib/openocd/tools/install/share/openocd/scripts/interface/stlink.cfg",
                "C:/ProgramData/chocolatey/lib/openocd/tools/install/share/openocd/scripts/target/stm32f1x.cfg"
            ]
        },
    ]
}

And there’s also the “tasks.json”

This is to integrate additional commands when using the launch.json, specifically when using the (now commented out) option of preLaunchCommands and preLaunchTasks.

For example, when is needed issuing a build before a compilation starts, by running automatically make. In this example I will not use it and run the compilation from the command line.

But here a snippet can be seen for reference on how it looks like:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Build all",
            "group": "build",
            "type": "shell",
            "command": "make",
            "args": ["all", "-j4"],
        }
    ]
}

Preparing a sample code

Now is time to actually put in the project some code to test the entire process. To do that an assembly startup file along with a main are placed in the project. I will use a basic division, in order to exercise and make visible later on the folder organization of CMake, using:

${workspaceRoot}/src/main.c -> obvioulsly the main file
${workspaceRoot}/src/startup/startup_stm32f103c8tx.s -> the startup file it will prepare for the main execution
${workspaceRoot}/build/STM32F103C8TX_FLASH.ld -> the linker file, which tells the compiler all the memory details of our microcontroller.

Note: don’t feel discouraged if the assembly and linker files seems complex. These files, except the <main.c> were taken from a working example for this microcontroller generated with the STM32 Cube MX, but can be reused and adapted accordingly.

More or less corresponding to the following:

Write a basic CMake file

This is the most complicated thing, especially if we need differnt folders, hence why the files separation. So after having worked on a bigger project using CMake, I kept the skeleton that will be important later in bigger projects. It looks more complicated, but will be way easier down the line as it gives scalability.

Here it is splitted in different files:
${workspaceRoot}/src/CMakeLists.txt -> it is the main CMake configuration, which merges together the other configurations in other subfolders (scalable CMake configuration is used)
${workspaceRoot}/src/startup/CMakeLists.txt -> it is the main CMake configuration used as an example to prepare the CMake information in a subfolder. The previous CMakeLists will take care of the libraries generated with this CMakeLists.
${workspaceRoot}/src/arm-none-eabi-gcc.cmake -> it is another hand written file containing informations specific to the compiler, making the CMakeLists more clean. Essentially, are defined all the path related to the compiler.

But here a quick breakdown of the main CMakeLists.txt, the one in the same folder of the main.c, as shown above. We have a first part, which contains all the compiler folder and output locations of the binaires. We are setting a default build type if not typed at invocation, it will access the arm-none-eabi-gcc.cmake, locate the linker file and enable the language settings desired:

# CMake template file

cmake_minimum_required(VERSION 3.15.3)

# Optional: print out extra messages to see what is going on. Comment it to have less verbose messages
set(CMAKE_VERBOSE_MAKEFILE ON)

# Path to toolchain file. This one has to be before 'project()' below
message(STATUS "CMAKE_SOURCE_DIR: ${CMAKE_SOURCE_DIR}")
set(CMAKE_TOOLCHAIN_FILE "${CMAKE_SOURCE_DIR}/arm-none-eabi-gcc.cmake")

# Setup project, output and linker file
# Check if CMAKE_BUILD_TYPE is not set or is empty
if(NOT CMAKE_BUILD_TYPE OR CMAKE_BUILD_TYPE STREQUAL "")
    # Set a default build type if none was specified
    set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "Default build type: Debug" FORCE)
endif()

# Now, you can use CMAKE_BUILD_TYPE in your CMakeLists.txt
message(STATUS "Build type: ${CMAKE_BUILD_TYPE}")
set(BUILD_FOLDER "${CMAKE_SOURCE_DIR}/../build/${CMAKE_BUILD_TYPE}")

project(AleaExample)
set(EXECUTABLE "${PROJECT_NAME}.elf")
set(EXECUTABLE_OUTPUT_PATH "${CMAKE_SOURCE_DIR}/../build/${CMAKE_BUILD_TYPE}")
set(LINKER_FILE "${CMAKE_SOURCE_DIR}/../build/STM32F103C8TX_FLASH.ld")

enable_language(C ASM)
set(CMAKE_C_STANDARD 11)
set(CMAKE_C_STANDARD_REQUIRED ON)
set(CMAKE_C_EXTENSIONS ON)

The second part will set the project name, contains the folders with the other CMakeLists in which CMake will look into, then it will put together all the sources and libraries generated by the other CMakeLists to the the same project output executable:

include_directories("${CMAKE_SOURCE_DIR}/startup")
add_subdirectory("${CMAKE_SOURCE_DIR}/startup")


#List of main source file
set(SRC_FILES   
"main.c"
)

file(GLOB AleaExample ${SRC_FILES})
add_executable(${EXECUTABLE} ${AleaExample})

Then it will setup the output files and debug information, which I always like to see clearly:

# Optional: Print executable size as part of the post build process
add_custom_command(TARGET ${EXECUTABLE}
        POST_BUILD
        COMMAND ${CMAKE_SIZE_UTIL} ${EXECUTABLE_OUTPUT_PATH}/${EXECUTABLE})

# Optional: Create hex, bin and S-Record files after the build
add_custom_command(TARGET ${EXECUTABLE}
        POST_BUILD
        COMMAND ${CMAKE_OBJCOPY} -O srec --srec-len=64 "${EXECUTABLE_OUTPUT_PATH}/${EXECUTABLE}" "${EXECUTABLE_OUTPUT_PATH}/${PROJECT_NAME}.s19"
        COMMAND ${CMAKE_OBJCOPY} -O ihex "${EXECUTABLE_OUTPUT_PATH}/${EXECUTABLE}" "${EXECUTABLE_OUTPUT_PATH}/${PROJECT_NAME}.hex"
        COMMAND ${CMAKE_OBJCOPY} -O binary "${EXECUTABLE_OUTPUT_PATH}/${EXECUTABLE}" "${EXECUTABLE_OUTPUT_PATH}/${PROJECT_NAME}.bin" 
        )

The project can anyway freely explored in its sources downloadable at the end of the article. If needed, a specific article about CMake can be written, but here syntax is shown as a starting example to see how should be more or less structured a CMake based project. Despite I am not a CMake expert, it is a solid starting point for a more complex project which we developed in the past, which can be always improved over time.

A nice, complete and complex CMake project that can be use as an example of the most sophisticated CMake usage freely accessible, is the RP2040 SDK.

Invoking CMake and finally compile

Now that all is set in place, we must call the Makefile generation via CMake. This is done via command line and normally this steps required to be done only once, unless file structure changes! Here is used the internal VSCode terminal as shown before (just clicking Terminal->New Terminal), and is used here the PowerShell.

The CMakeLists uses absolute paths generation, therefore the CLI commands can be issues from anywhere, and the location of the main CMakeLists should be indicated, but beware that with this configuration, the output MAKEFILE will be generated where the command is issued from. So with this configuration, we have two options:

  1. In the src folder, issue, including the final dot: cmake -DCMAKE_MAKE_PROGRAM=make -G "Unix Makefiles" .
  2. Outside of the src folder, i.e. one level up, issue cmake -DCMAKE_MAKE_PROGRAM=make -DCMAKE_TOOLCHAIN_FILE="arm-none-eabi-gcc.cmake" src
  3. We can also select the build type explicitly, otherwise by default, with this configuration, will always be “Debug”. Hence we can use whatever, like cmake -DCMAKE_MAKE_PROGRAM=make -DCMAKE_BUILD_TYPE=mamamia -G "Unix Makefiles"

In the option 2, the CMAKE_TOOLCHAIN_FILE must be explicitly set, otherwise it will use a default Windows compiler which obviously we don’t want, and the Makefile will be at a level up w.r.t. the src folder. If we use the option 3, before calling the command, we should be in the folowing position with the terminal:

After the correct invocation with option 3, the following structure, and the generated files, including the makefiles, are highlighted here:

Make it!

Finally the last step, calling make to compile our project. The call should be done wherever the Makefile is, in this case in the src folder.

In this case is sufficient to call make -j (it will use the CPU with the cores available more efficintly) or just make . This will output the binaries in the folder mamamia as follows:

Aaaand… debug!

Now that we finally managed to generate binaries, we just need to connect the MCU with the debugger as shown above in the hardware configuration, then clicking on the “Run & Debug” on the left (of press ctrl + shift + d) and then on the green arrow, next to the “STlink launch”, which was previously configured in the .json files:

But with the “mamamia” build type used for learning reasons, we discover that the .json files are limited. They have hard coded paths. So to debug, I will re-run the steps with the “Debug” build type, instead of “mamamia” 😀

I always advocate to experiment a bit, because we just learned 2 new things by doing something odd, like using a weird build type name:

  1. To regenerate the output files accordingly, you might notice that most of the time you have to delete the CMakeCache.txt, or we will not see the correct build type folder appearing.
  2. The .json files and the build type can be written in a different, more structured way. We have the basic, but to structure all accordingly, it will be worth another article

Anyway, enough was written for now. After clicking the green arrow (Start Debugging) or pressing F5, we can enjoy the firmware running on our microcontroller!

Sources

As promised throughout the article, here you can find the reference project on GitHub:

https://github.com/thexeno/aleae-codebase/tree/main/aleaengineering_ARM_makefiles_article

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Картинка для папки windows
  • Как восстановить загрузчик windows 10 после установки windows 10
  • Как отобразить кнопку пуск в windows 8
  • Включение отладчика ядра windows
  • Пропадает курсор мыши windows 10 в игре