За вопрос спасибо студентам группы 031/EE-01.
Буквой в скобках обозначаю (например, так: "(Щ)" ) моменты , на которые позже хочу сослаться.
Исходные данные: есть проект STM32CubeIDE (скажем, пустой, только что сгенерированный), теперь хочется его его скомпилировать и запустить на микроконтроллере.
Материалы: МК на базе stm32F401 (впрочем, конкретная модель не важна *), многострадальный ноутбук с Rosa Fresh 12.5.1, кубик версии 1.12 (люблю я именно эту версию…). Программатор — китайский свисток, которому повезло, что кубик его принимает за своего.
Если у вас windows, я предполагаю, что вы сами установили и настроили make, драйвер st-link и т. п. Также все консольные команды я даю в расчёте на bash, это стоит иметь в виду.
Итак, мы запустили кубоид, создали в нём проект, а теперь хотим закрыть кубоид и далее работать с этим проектом. На самом деле для того, чтобы всё получилось без лишней головной боли, сперва соберите проект в кубе. У вас создастся каталог Debug (ну, я пока предполагаю, что вы ничего не трогали), а в нём — исполняемый файл, и куча промежуточных файлов. Теперь вы можете сделать Project →Clean, при этом удалится большинство промежуточнх файлов, но останутся иструкции для утилиты make, которой мы и воспользуемся.
Для этого нам понадобятся
текстовый редактор. Любой;
утилита make;
компилятор, способный создать исполняемый файл для МК;
сервер gdb, способный работать по интерфейсу SWD с МК;
клиент gdb, умеющий в инструкции процессора МК.
С редактором, думаю, более-менее ясно.
Компилятор и клиент GDB можно достать из уже установленного кубоида (если у вас его в принципе нет, можно ограничиться пакетом STM32CubeCLT (CLT означает command-line tools). Там нам понадобится найти расположение файлов arm-none-eabi-gcc и arm-none-eabi-gdb.
Собственно, arm — это архитектура процессора, для которого мы собираем программу, none-eabi означает отсутствие какой бы то ни было ОС, взяимодействующей с исполняемым файлом (всяческие RTOS в данном случае не в счёт).
Вот по серверу есть варианты. Можно использовать openOCD, st-util либо stlink-gdbserver. Я буду использовать stlink-gdbserver просто потому, что он идёт в поставке с кубиком (на самом деле у него есть ещё два преимущества: он умеет более чем в одно подключение одновременно, а главное — в отладку двухъядерных МК).
Поищем (я предполагаю, что кубик установлен в /opt/st/stm32cubeide_1.12.0, в зависимости от ОС, кончено, нужно использовать подходящие инструменты для поиска):
aleksei@RNWS-008 ~ $ find /opt/st/stm32cubeide_1.12.0 -name 'arm-none-eabi-gdb'
/opt/st/stm32cubeide_1.12.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.linux64_1.0.200.202301161003/tools/bin/arm-none-eabi-gdb
aleksei@RNWS-008 ~ $ find /opt/st/stm32cubeide_1.12.0 -name 'arm-none-eabi-gcc'
/opt/st/stm32cubeide_1.12.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.linux64_1.0.200.202301161003/tools/bin/arm-none-eabi-gcc
aleksei@RNWS-008 ~ $ find /opt/st/stm32cubeide_1.12.0 -name 'ST-LINK_gdbserver'
/opt/st/stm32cubeide_1.12.0/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.0.500.202301161003/tools/bin/ST-LINK_gdbserver
(Б) На самом деле, конечно, это всё можно найти и глазами, но в любом случае с непривычки будет сильное желание выкинуть эти длинные буквы подальше.Пути до (не включительно) arm-none-eabi-gdb и ST-LINK_gdbserver следует добавить к системной переменной PATH (нет, как это делается, я здесь пояснять не буду, это относится не к нашей теме, а к общей компьютерной грамотности).
(Ъ) А вот путь до arm-none-eabi-gcc нужно добавить в PATH обязательно.
(В) Для использования ST-LINK_gdbserver нам отдельно понадобится путь к программе STM32_Programmer_CLI. Примерно так:
aleksei@RNWS-008 ~ $ find /opt/st/stm32cubeide_1.12.0 -name 'STM32_Programmer_CLI'
/opt/st/stm32cubeide_1.12.0/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_2.0.600.202301161003/tools/bin/STM32_Programmer_CLI
aleksei@RNWS-008 ~ $ export PATH_TO_PROGRAMMER='/opt/st/stm32cubeide_1.14.0/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_2.1.100.202311100844/tools/bin'
(А) Далее, make можно использовать как системный, так и из поставки кубоида (так же, поищите make). В принципе, нет причин не использовать штатный make — если только у вас не windows. Но тут подскажу мало: вживую видел make в составе платформы msys2, по идее, должно быть достаточно make из кубика. Точно так же, добавьте её в PATH, и будет работать.
Отлично. если вы проделали это — треть работы позади.
Теперь перейдём к сборке проекта. Для этого необходимо зайти в терминале в каталог с проектом, далее в каталог Debug (посмотреть, где он лежит, можно из Cube IDE: щелчок правой кнопкой мыши → Show In → System Explorer
ПКМ на каталоге → Show In → System Explorer
Теперь, узнав, где мы сидим (в моём случае это ~/STM32CubeIDE/other/test/Debug), открываем там терминал:
cd ~/STM32CubeIDE/other/test/Debug
и собираем проект (во всяком случае, те, кто не прогуливал лекцию про make):
make all
Для этого у нас должны быть установлены make (см (А) ) и переменная PATH должна указывать на каталог с arm-none-eabi-gcc (см. (Ъ)). Если make пишет что-то вроде /bin/bash: команда не найдена: arm-none-eabi-gcc), то возвращаемся к пункту (Ъ).
Если же эти два требования выполнены, то внезапно собирается. Почему?
Потому что в каталоге Debug кубик создаёт makefile, а также воссоздаёт примерную структуру каталогов проекта. В каждом из подкаталогов лежит фай subdir.mk, описывающий, как собирать данный подкаталог (в самом Debug эти инструкции вынесены в файлы с названиями objects.list, objects.mk, sources.mk). В принципе, мне по нраву такой подход. В сами файлы мы залезем чуть позже. А пока посмотрим, что получилось на выходе:
aleksei@RNWS-008 ~/STM32CubeIDE/other/test/Debug $ make all | grep -v arm-none-eabi-gcc
Finished building target: test.elf
arm-none-eabi-size test.elf
text data bss dec hex filename
5788 20 1580 7388 1cdc test.elf
Finished building: default.size.stdout
arm-none-eabi-objdump -h -S test.elf > "test.list"
Finished building: test.list
(grep -v использовал просто чтобы не выводить полотно текста).
У нас собрался файл Debug/lesson1.elf. Ура. Он модержит в себе инструкции и данные для работы программы; адреса, по которым эти инструкции и данные должны располагаться; отладочную информацию в соответствии с тем профилем сборки, который настроили в кубике — для Debug это практически весь исходный текст программы. Он нам и понадобится далее.
Теперь треть работы позади.
Подключаемся к МК.
Как уже упоминал, работать будем с ST-LINK_gdbserver; при желании можете использовать st-util, она чуть проще в запуске, а результат для нас будет тем же. Или openOCD, если он у вас уже есть.
Предполагаю, что (Б) и (В) мы уже прошли. Тогда запускаем:
ST-LINK_gdbserver -p 4242 -d -t -cp $PATH_TO_PROGRAMMER
Здесь -p 4242 — это указание порта для работы с клиентом gdb; по умолчанию ST-LINK_gdbserver использует 61234, делайте как вам удобно, я обычно пишу его явно, чтобы не забыть.
-d — использовать SWD (подозреваю, что ключ необязателен).
-t — тоже необязательный для нас, разрешает множественные подключения.
-cp $PATH_TO_PROGRAMMER — обязательно нужно указать путь к STM32_Programmer_CLI (см. (В))
Если контроллер подключён, то увидим сообщение типа Waiting for debugger connection
Это означает, что мы смогли подключиться по USB к программатору и через него к целевому контроллеру. Если не смогли — проверяем контакты (в том числе разрешение на доступ к USB, мало ли…)
Далее в отдельном терминале заходим в каталог с файлом elf и запускаем клиент отладчика. Примечание для пользователей windows: здесь следует использовать именно стандартный терминал windows, штуковины типа git bash или терминала msys2 в данном конкретном случае не дадут работать автодополнению клиента gdb.
aleksei@RNWS-008 ~/STM32CubeIDE/other/test/Debug $ arm-none-eabi-gdb
(gdb) target extended-remote :4242
Remote debugging using :4242
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x08015760 in ?? ()
(gdb) file test.elf
Reading symbols from test.elf...
(gdb) load
Loading section .isr_vector, size 0x298 lma 0x8000000
Loading section .text, size 0x1bc5a lma 0x8000298
Loading section .init, size 0xc lma 0x801bef4
Loading section .fini, size 0xc lma 0x801bf00
Loading section .rodata, size 0x10444 lma 0x801bf0c
Loading section .eh_frame, size 0x4 lma 0x802c350
Loading section .ARM.exidx, size 0x8 lma 0x802c354
Loading section .data, size 0x9ec lma 0x802c35c
Loading section .init_array, size 0xc lma 0x802cd48
Loading section .fini_array, size 0x4 lma 0x802cd54
Loading section .init_array.00000, size 0x4 lma 0x802cd58
Start address 0x08007a24, load size 183642
Transfer rate: 41 KB/sec, 8347 bytes/write.
(gdb) continue
Continuing.
Собственно, программа запущена. Далее изучайте команды gdb (начните с: breakpoint, info breakpoint, delete, next, step, continue, run, disconnect, target, quit, print, x, frame; несколько особняком — dump, потому что на тему неё я позже ещё напишу пару слов). Имейте в виду, что здесь работает автодополнение команд (клавишей Tab), история (клавиши «Вверх» и «Вниз»), поиск по истории (Ctrl + r), сокращения команд (например, 'c' эквивалентно continue). Также если нажать ВВОД при пустой строке ввода, будет повторена последняя команда (это не очень удобно, но увы, без пересборки gdb этого не исправить; для отдельных команд можно отменить повтор последней команды при помощи «dont-repeat».
В следущей серии помигаем светодиодиком.
