Как установить st link v2 linux

Обновлено: 03.07.2024

Для разработки системы управления одной железякой после длительных поисков мною был выбран ARM-микроконтроллер семейства STM32 — STM32F103 (в «стоножечном» исполнении). А в качестве макетки для разработки и отладки — STM32P103 (там ножек хоть и меньше, но ядро то же самое). «Истории успеха» я понемногу выкладывал в своей ЖЖшке, но вот решил собрать все воедино и рассказать о том, каково же оно — программировать микроконтроллеры в линуксе. Сам проект лежит на sourceforge.

Прежде всего коснусь общего, а потом уже перейду к деталям.

Итак, помимо макетки (или же готового устройства — когда оно будет готово) потребуется JTAG-адаптер. В моем случае это — ST-LINK/V2. Одного железа, естественно, недостаточно: надо еще как-то код компилировать, а потом еще и заливать на контроллер. Для этого были установлены компилятор gcc для ARM (arm-none-eabi) и утилита для работы с ST-LINK (она так и называется — stlink).

В качестве образца я взял этот проект. Отсюда я скачал простенькие демонстрационные проекты и попробовал скомпилировать простейший. А самым первым оказался стандартный Helloworld для МК: мигание светодиодом.

Сразу скажу, на какие грабли я напоролся с самого начала: я забыл про objcopy, без которого получить работающий код будет сложновато. После компиляции проекта обязательно надо создать бинарник при помощи этой утилиты. И не стоит выкидывать из Makefile'ов непонятных (и вроде бы даже ненужных на первый взгляд) целей.

В качестве удобного IDE я использую Geany. Так как на работе у меня два монитора, довольно удобно работать: на одном мониторе у меня открыт Geany с кодом, а на втором — терминал, где я запускаю make и com (терминал из tinyserial).

Весь Makefile я рассматривать не буду, обращу лишь внимание на то, что в нем следует менять:

BIN — имя получающегося после компиляции бинарника
STM32_LIBSRC и OBJ содержат подключаемые файлы библиотеки STDPeriphLib, неиспользуемые надо закомментировать
SRC сдоержит перечень пользовательских исходников

После того, как код написан, запускаем make. Если все в порядке, в текущей директории появится файл $(BIN).bin, который и нужно записать во флеш-память МКшки. Запись выполняется при помощи make load: эта цель сборки просто вызывает st-flash для прошивки микроконтроллера.

Итак, прежде всего необходимо наладить связь компьютера и МКшки. Учитывая то, что в современных компьютерах RS-232 отсутствует, отладочную связь организую посредством USB. Однако, в «боевых условиях» команды МКшка будет получать по RS-232 от другого контроллера, поэтому я решил сразу же смотреть в сторону организации эмулятора переходника USB<->RS-232. Этот подход удобен еще тем, что не надо заморачиваться с лишним кодом для взаимодействия с устройством по USB (хоть это и элементарно, но лень же!). Да и отлаживать просто: открываем устройство /dev/ttyACM0 как последовательный порт при помощи любого эмулятора последовательного терминала и «общаемся». Да, в качестве эмулятора терминала на первых порах (пока нет никакого ПО со стороны компьютера) я использовал tinyserial.

Отсюда я скачал код эмулятора переходника USB<->RS-232. Так как проверить работоспособность второй стороны (RS-232) я сразу не мог (некуда подключить), неиспользуемый код работы с USART временно закомментировал.

Для работы с USB используется библиотека от STMicroelectronics. Если не вникать в коды самой библиотеки, все довольно-таки просто: нам нужно переопределить дескрипторы для своей железяки (файлы usb_desc.[ch]), чтобы компьютер опознал ее как переходник USB<->RS-232, а также изменить обработчики прерываний на события USB (как минимум — обработать принятые данные, а для прозрачной работы в качестве переходника, надо будет еще добавить обработку прерываний USART для передачи полученных оттуда данных по USB).

Так как некоторые команды (например, чтение температуры с 1-wire датчиков) выполняются довольно-таки долго, обработчик пришедших по USB команд только модифицирует флаги для подобных операций, а уж основной цикл в main() эти флаги обрабатывает. Операции, выполняющиеся быстро (работа со светодиодом), вызываются непосредственно из этой функции. В отладочных целях я добавил «эхо» на команды в виде краткой ее расшифровки:

Все, теперь при подключении макетки к компьютеру по USB (а она, вообще-то, у меня всегда подключена, т.к. питается через USB) появляется устройство /dev/ttyACM0, с которым можно работать, как с обычным последовательным портом. Например, открыть его при помощи последовательного терминала (как я уже выше сказал, на первых порах пользуюсь tinyserial).

Светодиод, кнопка

Наверное, традиционным является «помигать диодом» в начале изучения какой-нибудь новой железяки, поэтому и я сделаю так же. А заодно повешу на «user button» прерывание, которое будет менять режимы работы светодиода.

Просто мигать не интересно: интересно менять яркость. Для этого достаточно простого «софтового» ШИМа. Настроим таймер SysTick на период в 10мкс. Заведем два счетчика: один для количества «тиков», в течение которых светодиод горит, а второй — для количества «тиков», в течение которых светодиод не горит. Для изменения яркости свечения светодиода я сделал простейшую восьмиуровневую схему изменения скважности ШИМа.
Получилось вот что:

На «пользовательскую кнопку» я повесил внешнее прерывание:

А его обработчик занимается тем, что переводит светодиод в режим непрерывного свечения, если тот «мигал», или наоборот — в режим «мигания», если тот светился:

1-wire

В сворованном мною примере 1-wire работала через USART, а для чтения/записи использовался DMA. Мне эта идея очень понравилась, поэтому воспользовался именно этим способом (хотя можно было организовать и программный протокол 1-wire).

Стандартная схема подключения 1-wire шины к последовательному порту подразумевает наличие диода Шоттки:

Однако, у меня такого диода не было. Но я углядел, что помимо push-pull режима можно отвечающую за USART_TX ногу перевести в режим с открытым стоком — в этом случае короткого замыкания не будет. Для работы с 1-wire я использовал USART3 (пока я балуюсь, ног мне хватает — поэтому remap делать не надо). На схеме я увидел, что ноги USART3 (PB10 и PB11) уже подтянуты к земле через резисторы по 10кОм, так что мне даже резистор припаивать не пришлось: только подпаял на макетку небольшую платку с гнездами, чтобы удобно было подключать термодатчики.

Подробно расписывать содержимое файла onewire.c не буду: это сделано уже до меня неоднократно, а коснусь лишь непосредственно работы с термометрами.

Для мониторинга температуры теплых (выше -50°C) частей устройства я решил воспользоваться простыми датчиками DS18S20 (заявленная точность измерения — не хуже 0.5°C). Подпаянную на макетку панельку я подключил к нужным выводам, чтобы можно было одновременно подключить к МКшке пару термометров.

Вот, например, что я получаю при работе с термометрами:

Для начала я промаркировал все термометры, чтобы знать, какой идентификатор у кого. А после я решил посмотреть, сильно ли различаются их показания. Температура — первые два байта ответа датчиков. В седьмом байте хранится «остаток» от преобразования температуры встроенным в термометр АЦП. По документации на датчики, этот остаток помогает уточнить значение температуры. Однако, выяснилось, что толку от него — как от козла молока.

В процессе работы датчик сам нагревается, что сказывается на результатах измерения. Поэтому не стоит слишком часто их опрашивать. Кроме того, показания датчиков отличались друг от друга вплоть до полутора градусов! Это нужно иметь в виду: если планируется использовать несколько датчиков так, чтобы мониторить разницу температур между участками чего-то с точностью не хуже 0.5°C, предварительно надо все датчики откалибровать. И показания брать по калибровочным формулам, а не ответу датчиков.

Реальная погрешность датчика иной раз превышает 0.5°C, поэтому все-таки лушче считать, что датчик имеет точность в 1°C.

Датчик Холла

Датчики Холла у меня аналоговые — SS495A. Спецификации на датчик можно найти в интернете. Скажу лишь, что в нормальном состоянии на его выходной ноге напряжение составляет около 2.5В (логическая единица STM32), в зависимости от полярности и величины внешнего магнитного поля он будет изменять свои показания в пределах 0..5В. Учитывая то, что напряжение на выходе может достигать пяти вольт, надо использовать не обычные, а «пятивольтовые» (обозначены как FR в спецификации) входы контроллера.

Имеющиеся у меня магниты (специально для этого датчика) при помещении их рабочей поверхности в пределах 1мм от «морды» датчика (маркированная сторона) приводили к появлению на его выходе нулевого напряжения. Причем уровень логического нуля появляется в довольно-таки небольшой зоне по координатам в параллельной маркированной стороне датчика плоскости, т.е. точность позиционирования получается довольно приличной.

Для опытов я распаял на макетке один датчик. Питание его подключил к 5В, а сигнальный выход вывел на порт PC10, который не сгорит, если на него подать 5В. Для того, чтобы не дергать постоянно порт, я повесил на него прерывание (по аналогии с кнопкой). Обработчик прерывания просто выставляет соответствующий флаг, а уж в основном цикле, если этот флаг выставлен (т.е. магнит либо появился, либо покинул «поле зрения» датчика) проверяем, что у нас на PC10. Если там ноль (есть МП), пишем в терминал «Magnet», иначе пишем «clear». Еще можно принудительно проверить, есть датчик или нет его, нажав «h» в терминале.

Помимо «теплых зон» мне еще надо будет измерять температуру в холодных (вплоть до 75К сверху). Для этого будут использоваться платиновые термосопротивления, подключенные к аналоговому коммутатору ADG506A. Ну и, естественно, мне стало интересно, насколько плох «родной» АЦП МКшки: нельзя ли его использовать для измерения температуры?

Примеров работы STM32 с АЦП полным-полно, я взял пример из STDPeriphLib. Будем запускать АЦП в режиме непрерывного преобразования, а результат заносить в память при помощи DMA. Время преобразования устанавливаю в самое большое (чтобы поточнее было), а сам вход АЦП пока что повешу на ногу PB0 (ADC8):

Для работы с коммутатором нужно сконфигурировать пять бит управляющего порта. Чтобы не париться с преобразованием бит, я просто взял первые четыре бита порта C в качестве адреса, а пятый бит — в качестве ключа, включающего коммутатор:

Прерываний здесь никаких не надо, а в файле interrupts.c надо дописать установку нового флага при поступлении команды (скажем, команды 'a') отображения напряжения на датчиках. В main() добавим обработку этого флага:

В общем, надо будет либо попробовать добавить стабильный источник опорного напряжения (да и измеряемую цепь питать оттуда же), либо вообще использовать внешний АЦП. Учитывая низкое сопротивление датчиков, которые будут использоваться, все равно придется паять еще и усилитель.

Шаговый двигатель

С шаговиком я еще не закончил возиться, т.к. подозреваю, что при монтаже элементов на макетке у меня ничего «не взлетит». Надо паять. А пайкой займусь, скорее всего, только в следующем году (надо еще радиодеталей прикупить). Пока лишь вкратце расскажу, как планирую управлять шаговыми двигателями.

Шаговики у меня будут — VSS42 на 1.2 ампера. Управлять такими удобней всего при помощи драйвера ШД — L6208. При работе на эту микросхему надо подавать лишь сигналы управления направлением движения, сигнал разрешения работы да тактовые импульсы. Контроллер сам регулирует ШИМ и устанавливает нужные напряжения на обмотках двигателя.

рекомендуется к прочтению

Справочное руководство по 32-битным микроконтроллерам серий STM32F10x Reference Manual. STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx and STM32F107xx advanced ARM®-based 32-bit MCUs или RM 0008
Руководство на чипы STM32F103x8/STM32F103xB STM32F103x8 STM32F103xB Medium-density performance line ARM®-based 32-bit MCU with 64 or 128 KB Flash, USB, CAN, 7 timers, 2 ADCs, 9 com. interfaces Книга не обязательная, но на мой взгляд очень полезная.

Небльшой ликбез по ARM и Cortex-M3 в частности:

Cortex-M3 основан на архитектуре ARMv7 и является усеченным вариантом архитектуры ARMv7 специально для микроконтроллеров. По сравнению с полноценным ЦПУ Cortex-A, здесь отсутствует кеш и 32-битный альтернативный набор команд ARM. Также могут отсутствовать некоторые модули, такие как модуль зашиты памяти - MPU (Memory Protect Unit).
Cortex-M3 включает в себя 16-битный набор команд, оптимизированный для систем с малым объемом памяти, Thumb и 32-битный дополнительный набор Thumb-2. Здесь 16-битная команда означает, что ее двоичное представление будет занимать в памяти 16-бит, т.е. она более компактная. Программный код может состоять из произвольного набора 16-битных команд Thumb и 32-битных Thumb 2.
В Cortex-M3 имеется аппаратное деление и умножение. Урезанная, удешевленная версия Cortex-M0 базируется на архитектуре ARMv6 и таких инструкций не имеет. ARMv6 отличается от ARMv7 отсутствием набора инструкций Thumb-2. Cortex-M4, напротив, дополнен DSP модулем, а Cortex-M4F также включает в себя FPU модуль, т.е. он аппаратно поддерживает числа с плавающей запятой.
Номера процессоров ARM никак не согласованы с версиями архитектур. Процессоры ARM11 имеют архитектуру ARMv6, а ARM9 имели архитектуру ARMv4.
Cortex-M3 имеет единую адресную 32-битную шину, которая может адресовать 4Гб памяти. Процессор построен по гарвардской архитектуре и имеет отдельные шины для памяти данных SRAM и памяти программ Flash. Программа может быть запущена из SRAM, тогда будет задействована только одна шина и код будет выполняться медленнее.
Cortex-M3 имеет шестнадцать 32-битных РОН (регистров общего назначения) R0-R15. Команды из набора инструкций Thumb могут обращаться только к регистрам R0-R7. Команды из набора Thumb-2 могут обращаться ко всем регистрам. При этом, регистр r13 - это указатель стека, r14 - регистр связи(хранит адрес возврата из подпрограммы), r15 - счетчик команд.

Немного о STM32:

Выпускаемые линейки микроконтроллеров изображены на следующей картинке:

Это не полный перечень, но представление давать должен. Кроме линеек, микроконтроллеры делятся по размерам flash-памяти. Чем больше flash-пямять, тем больше остальной периферии. Для 103-й линейки это выглядит так:

Блок-схема устройства STM32F103 представлена на картинке ниже:

Во всем этом хозяйстве нас будет больше всего интересовать периферия подключенная к периферийным шинам APB1 и APB2. Также полезно будет запомнить внутреннюю шину AHB.

Имеющаяся в чипах периферия перечислена в следующей табличке:

Выбор "железа"

Чип который у меня оказался под рукой - STM32F103CBT6 запаянный в плату Maple Mini:

Заказав его год назад на Али, я ради интереса загрузил в него несколько скетчей, и набалововшись бросил на полку. За этот год проект Leaf Maple накрылся медным тазом, сайт поменял содержимое, а поддержку железа передали на следующий форум: STM32 for Arduino. Я особо не расстроился, т.к. не питал особых надежд на этот проект, и планировал плату использовать для Си-программирования.

Кстати, на упомянутом выше сайте есть хороший классификатор с образчиками результатов работы китайской промышленности, содержащих чипы STM32F103, очень рекомендую ознакомится: STM32F103 boards

Если у кого-то имеется под рукой "Blue Pill", то это не беда, там установлен чип STM32F103C8T6 который от STM32F103CBT6 отличается только уменьшенным до 64кБ размером flash-памяти. Еще там светодиод подключен на PC13, в то время как на MapleMini он на PB1, и кроме этого у Maple Mini имеется кнопка на PB8.

Зато на "Blue Pill" имеется штыревой разъем для подключения программатора ST-LINK, в то время как Maple Mini нужно устанавливать в макетку что бы прошить по SWD. Прозвонкой чипа было выяснено, что на Mapple Mini SWDIO контакт "висит" на 22-pin, а SWCLK на 21-м. Но заставить работать ST-LINK с Maple Mini оказалось не просто.

Прошивка чипов через программатор ST-LINK v2

STM32 можно прошить либо через UART встроенным загрузчиком, либо через SWD-интерфейс программатором ST-LINK. Меня интересовал второй вариант, т.к. был скромным владельцем клона ST-LINK v2.

В Windows прошить STM32 через ST-LINK можно воспользовавшись фирменной утилитой "STM32 ST-LINK Utility", или непосредственно из среды разработки IAR for ARM. В Linux можно воспользоваться консольной утилитой sy-flash.

Если у вас "Blue Pill" или еще какая-либо плата отличная от Leaf Maple, то никаких проблем не будет, их можно сразу прошивать. Моя же Maple Mini никак не хотела видеться программатором, пока я не догадался во время загрузки программы из IAR в чип, несколько раз нажать на кнопку Reset на плате. После чего Maple Mini начала свободно прошиваться, но родной USB-загрузчик был на этом этапе потерт. Но это мелочи.

Ок. Посмотрим как чипы прошиваются в Windows. Войдя на сайт http://my.st.com и залогинившись, введем в строку поиска "st-link". На выходе получим такую табличку:

Щелкнув мышкой по второй строчке и промотав открывшуюся страницу книзу, увидим список предлагаемого ПО для программатора:

STSW-LINK004 - это утилита для прошивки STM32 чипов. STSW-LINK007 утилита для обновления прошивки программатора, STSW-LINK009 - драйвера для различных версий Windows. Немного выше предлагаются свежие прошивки для самого программатора. ST-LINK v2.

Как установить драйвер для ST-LINK v2 я рассказывал здесь: STM8 + IAR + ST-LINK2: программирование, прошивка и отладка из под Windows, поэтому далее будем считать, что драйвер уже установлен.

После установки и запуска "STM32 ST-LINK Utility" следует подключить ST-LINK v2 к компьютеру или виртуальной машине(мой случай), а к ST-LINK в свою очередь, должен быть подключен чип который следует прошить:

После чего следует пройти по меню: "меню-> Target - > Settings. " и должно появится такое окно:

Во-первых, сам программатор ST-LINK V2 должен быть опознан программой, показана версия его прошивки. Во-вторых должен быть опознан чип подключенный к программатору. В третьих, рабочий протокол должен быть установлен как SWD, а не JTAG.

Когда я впервые воткнул ST-LINK полученный год назад с Али, мне вместо номера прошивки показывало что-то вроде "Old firmware", поэтому мне пришлось воспользоваться утилитой обновления прошивки ST-LINK, что бы флешеры нормально работали с моим клоном ST-LINK. К сожалению у меня не сохранились скрины.

Здесь у меня изначальная версия прошивки(цифра после буквы J) была то ли 20, то ли 21. В итоге меня обновили то текущей версии. Кстати, из под виртуальной машины обновляется прошивка без проблем.

Вернемся к STM32 ST-LINK Utility. После нажатия кнопки "Ок" в окне "Settings", появится рабочее окно программы:

Следует запомнить, что стартовый адрес флеш-памяти начинается с 0x08000000. Встроенная оперативка начинается c 0x20000000. Чтобы программа стартовала с оперативки, контакты boot0 и boot1 должны быть сконфигурированы специальным образом.

Щелкнув по вкладке "binary file" можно выбрать файл с прошивкой, затем пройдя по "меню->Target->Program. " эту прошивку можно прошить в микроконтроллер:

Наряду со знакомым форматом прошивок HEX, в stm32 широко используется бинарный raw-формат "*.bin".

Через меню "File->Save As" можно сохранить прошивку чипа в файл:

Если честно, слить пошивку с чипа и потом залить ее обратно так, чтобы она работала, мне не удалось. Нужно будет разбираться.

Еше интересной штукой являются Option Bytes знакомые по STM8:

Пока не будем их трогать.

Теперь, что касается st-flash для Linux, то там с одной стороны все проще, а с другой - сложнее. Сложнее, потому что глючит. Может к этим глюкам как-то можно привыкнуть, но я пока не сумел.

Пока я обнаружил такую закономерность, команда очистки флеш-памяти "st-flash erase" помогает избавиться от глюков:

Программирование STM32 с помощью IAR и SPL в Windows

Если на сайте http://my.st.com ввести в строку поиска "stm32f10x standard peripheral library" то нам предложат скачать SPL для чипов STM32F10x:

В отличии от SPL для STM8, библиотека разделена на CMSIS и саму SPL. CMSIS (Cortex® Microcontroller Software Interface Standard) - это стандарт описания периферии микроконтроллера, то что в STM8 размещалось в файлах stm8s.h/stm8l.h

Подключить SPL к IAR достаточно просто, в сети множество видео и пошаговых инструкций. Я лично делал по этому видео: STM32 Discovery IAR and StdPeriph Lib настройка и загрузка проекта

Проект компилируется и заливается в чип, после чего успешно работает. Наверное больше и не надо, но я предлагаю забрать результирующий объектный файл с расширением *.out и перенести его в Linux, для внимательного изучения:

Программирование STM32 с помощью Eclipse и SPL в Linux

В Linux попробуем посмотреть, что за файл генерирует на выходе IAR:

Как видим, это обыкновенный эльф. Смотрим дальше:

Из "эльфа" мы всегда можем получить файл прошивки в HEX формате:

или бинарный файл:

Также можно посмотреть ассемблерный код:

Даже можно попытаться загрузить на чип в режиме отладки. Для этого понадобиться сервер st-util который входит в набор утилит st-flash и сам отладчик gdb.

Подключаемся к ранее запущенному серверу:

Ставим точку останова и запускаем на исполнение:

кое-что сделать конечно можно

На этом этапе думаю лучше оставить прошивку с IAR в сторону, и попытаться скомпилировать нормальный объектный файл в Linux.

некоторые не ищут легких путей.

Проблема в том, что нельзя вот так просто взять компилятор, исходный текст и скомпилировать прошивку для stm32. Почему? Потому что в опциях gcc компилятора можно указать только тип архитектуры "cortex-m3", а чипов на этой архитектуре выпускаются различными фирмами - тьма тьмущая. И у всех них разные карты памяти и периферия. Как минимум понадобиться скрипт линкера для вашего чипа.

О масштабах проблемы можно почитать например тут: ARM-ы для самых маленьких: тонкости компиляции и компоновщик. Более-менее толковый самопальный Makefile который мне удалось найти можно взять тут: Еще один шаблон проекта под STM32 на gcc.

После некоторых размышлений я решил взять в качестве основы сборочные файлы из какого-нибудь IDE. Традиционным IDE для ARM в Linux стал Eclipse, который ненавидят наверно все linux-пользователи за глючность и тормознутость. Справедливости ради, должен упомянуть, что генерации проектов существует специальная фирменная утилита STM32CubeMX. Но может ли она генерировать проекты для gcc или нет, я не знаю.

Поддержка ARM в Eclipse ставится через плагин: GNU ARM Eclipse

На странице установки предлагается несколько способов установки ARM плагина. Но, например, на LinuxMint мне этот плагин установить не удалось. В репозитории какая-то древняя версия Eclipse 3.8, это версия от 2012(!) года. И установка плагина заканчивается фейлом:

Поэтому пришлось вспомнить про старую добрую Slackware GNU/Linux. В этом году вышла новая версия 14.2.

Для начала нужно будет скачать ARM toolchain c сайта ARM:

Скачанный архив я распаковал в /usr/local

Теперь чтобы скачать Eclipse, зайдем в репозиторий и введем в строку поиска "eclipse-cpp":

После чего попадаем на страницу с пакетом:

Т.к. уменя Слакваръ 64-битная, то для установки выполняем следующие манипуляции:

Теперь можно запускать Eclipse:

Жмем OK, это будет рабочий каталог проектов:

Далее открываем Marketplace:

В строку поиска вводим ARM:

и щелкаем по "install"

Перед установкой нужно будет принять условия лицензии:

Если погода на Марсе будет солнечной, то в конце установки предложат перезагрузить Eclipse:

После перезапуска Eclipse создаем новый проект:

В открывшийся форме нужно будет заполнить имя нового проекта и выбрать его тип:

В следующей форме необходимо выбрать параметры чипа. Замечу, что по дефолту(поле Content) предлагается не пустой проект, а проект с blink'ом:

Следующую форму можно оставить как есть:

Здесь нужно указать путь к папке toolchain'ом:

Осталось закрыть окно "Welcome"

И перед нами открывается окно проекта:

Это совсем не тот простенький Blink который был в IAR. Здесь задержки формируются по таймеру и кроме этого используется модуль трассировки. Задать номер pin'а к которому подключен светодиод, можно в файле Blinky.h

Чтобы задать светодиод на PB1 нужно константы BLINK_PORT_NUMBER и BLINK_PIN_NUMBER установить в единицы. После чего можно скомпилировать проект:

Если все прошло удачно, то можно закрыть проект и перейти в консоли в папку проекта:

Там будет объектный файл прошивки. Получаем бинарный файл:

Если, опять же все нормально, то светодиод начнет мигать с интервалом в одну секунду. Заливать прошивку можно и из Eclipse, но эта IDE меня интересует только как генератор проектов.

Попробуем взглянуть на makefile файл который лежит в этой же папке:

некоторые вещи бывает сложно объяснить

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

подключаемся к серверу:

ставим точку останова:

Запускаем на выполнение:

Выполнение программы приостонавливается на точке останова. Смотрим листинг:

В этот раз все в прорядке. Однако если мы еще раз дадим команду continue, то будет возможно, неожиданный эффект:

Программа останавливается по сигналу SIGTRAP и дальше ни в какую не идет.

Чтобы решить эту проблему, нужно в Eclipce через меню->project->proporties, открыть вкладку Settings в "C/C++ Build":

В настройке препроцессора следует удалить макроопределение OS_USE_TRACE_SEMIHOSTING_DEBUG. После чего пересобрать проект. и полученный объектный файл заново загрузить в отладчик:

Посмотрим что нам пытаются вывести:

здесь вроде все нормально

Посмотрим значение переменной seconds:

Почему то у меня после blink_on() светодиод гаснет, а после blink_off() наоборот загорается

он весьма тормознутый, поэтому на всякий случай перезалил в облако:

1) Распаковываем файл st-stm32cubeide_1.50.sh из архива, двойное нажатие по нему приведет к созданию папки с таким же именем.

2) Открываем папку, она будет содержать различные файлы (может придется подождать десяток сек):

3) Запускаем терминал ( Ctrl + Alt + T) и пишем путь к создавшейся папке (можно скопировать из строки сверху):

4) Теперь меняем права (это может и не понадобится) и вводим пароль, который запросит:

sudo chmod a+x install.sh

5) Далее непосредственно запускаем файлик установки:

6) Появляется лицензионное соглашение, жмём Ввод (Enter), пока оно не закончится. Принимаем его (прописав игрек в командной строке):

6)Указываем путь установки (папку создавать не нужно):

7) Ждём, пока установится. Высветится окно для ввода пароля, вводим.

8) Откроется окошко с установкой SEGGER J-Link и спросит продолжать ли (Do you wish to continue?). Пишем:

9) Теперь листаем долгий текст (Enter) и соглашаемся со всем (Do you agree with the terms of this license?):

10) Скорее всего таким же образом будет установка двух программ: ST-Link и ST-Link Server.

На этом всё, можно использовать бесплатную среду разработки для программирования микроконтроллеров STM32 на бесплатной операционной системе Linux.

Но прежде всего, вам необходимо знать, что эта программа поддерживает несколько плат программаторов и отладочных плат со встроенным программатором. На этих платах установлен микроконтроллер, который транслирует команды с USB в JTAG. Эта микросхема вместе с ее окружением называется stlink. Причем на данный момент на рынке имеется две версии:

STLINKv1, присутствует на платах STM32VL-discovery,
STLINKv2, присутствует на плате STM32L-discovery и на плате STM32F4.

Версии отличаются на транспортном уровне:

Общие требования

Перед установкой stlink Вам нужно установить пару пакетов: libusb-1.0-0 и pkg-config.

Возможно, первый пакет у вас уже установлен, но на всякий случай лучше еще раз повторить установку. Это нужно сделать, чтобы получить более свежую версию.

Возможно, вам понадобится также установить еще пакеты git git-core или libusb-dev.

Для Ubuntu еще понадобится установить пакет libsgutils2-dev.

Если у вас STLINKv1

Не отчаивайтесь! Вообще говоря, эмуляция SCSI в STLINKv1 реализована довольно-таки криво. Поэтому лучше сразу сказать операционной системе, чтобы она полностью игнорировать ее. Таким образом, перед тем как воткнуть плату в USB разъем, выполните любое действие из следующих трех:

1. Выполните команду:

3. Выполните команды:

Эти действия вам нужно выполнить после установки установки.

Если у вас STLINKv2

Танцы с бубном отменяются. Вам ничего делать не надо, всё и так будет работать.

Установка stlink

Чтобы получить к себе в комп точную копию проекта, нужно выполнить команду клонирования:

Если вы еще не устанавливали пакет git или git-core, то вам нужно сначала установить его, и только потом клонировать проект stlink. Как установить git, я уже писал в своем блоге. Поищите сами.

Итак, через несколько минут примерно 10 МБайт будут закачены в комп, и в директории, из которой вы выполнили команду клонирования, появится поддиректория проекта stlink. Заходим в нее.

Вот, что мы получили после нее:

Однако, в процессе конфигурирования у меня выскочила ошибка:

На этот раз всё прошло удачно. Более того, в директории появился файл Makefile, читая который команда make произведет сборку программы. Не тормозим, скорее запускаем сборку:

Ну вот и всё! Можно считать, что клонирование, сборка и установка пакета stlink произведена почти полностью и успешно.

Заметьте, копирование производиться в системный директорий, поэтому нам опять понадобится подняться на уровень root-а.

В следующий раз, напишу, как с помощью stlink портить отладочные платы STM32VLDISCOVERY.

Если вы готовы уже прямо сейчас стирать и записывать свои проги в отладочную плату, не забудьте выполнить подновление системы udev, чтобы изменения вступили в силу:

Таким образом, udev создаст целую кучу устройств /dev/stlinkv1_XX.

J-LINK — замечательный отладчик, но что делать владельцам ST-LINK'а или STM32Discovery?
В одном из комментов к этой статье уважаемый evsi оставил ссылочку на проект, в состав которого входит GDB сервер, с названием st-util, и заточенный под ST-LINK. Подумаем как его интегрировать в Eclipse. Тем, кто устанавливает тулчейн с нуля, первые три пункта плана можно взять из той же статьи, а OpenOCD заменить на st-util…

Процесс установки предельно прост

Теперь — основная задача, прикрутить это к Eclipse.
В отличие от OpenOCD, st-util завершает свою работу сразу после того, как от него отключится GDB клиент. То есть, нам нужно запускать st-util перед началом каждой сессии прошивки и отладки. Для этого:
Меню Run->External Tools->External Tools Configurations…
и создадим запускалку для st-util. По умолчанию st-util слушает порт 4242, и если есть желание использовать другой порт, укажите его значение в параметрах: -p 3333

Далее жмём Apply, подключаем (заранее) ST-LINK с пациентом к компу и жмём Run, после чего получаем такую картину:

Замечание по поводу ST-LINK'а. У меня после подключения к компу отладчик «тупит» некоторое время, т.е. в списке $ lsusb устройство появляется сразу, а вот st-util (или утилитка test_usb, которая тоже входит в этот проект) может подключиться к отладчику только секунд через 20. Помнится в Windows такой ерунды не было. Не знаю, бага это или фича… Утилита test_usb, как я понял, служит для тестирования подключения отладчика к компу, отображая по этому поводу некоторую информацию. С пол-года назад я пытался заставить работать этот st-util, но тогда то ли лыжи не ехали, то ли я что-то не так делал, в общем, всё, чего я смог добиться, так это залить прошивку из консоли. И проект этот тогда лежал не на GIT'е, а совсем в другом месте. Но, как мы видим, проект развивается.

Теперь создадим конфигурацию для запуска GDB.
Сначала удалим из списка лишние варианты, чтобы они нам не мешались, хотя это и не обязательно.
Меню Window->Preferences->Run/Debug->Launching->Launch Configurations

Далее, Меню Run->Debug Configurations…

Создадим конфигурацию для запуска st-util + GDB.
Для того, чтобы запускать друг за другом разные конфигурации, в Eclipse предусмотрен вариант Launch Group:

Именно эта конфигурация и будет запускать процесс прошивки/отладки.

Создадим ещё одну конфигурацию для того, чтобы отлаживаться без лишней прошивки контроллера, если исходный код не менялся. Её можно продублировать от уже имеющейся, на вкладке Startup снять галки Load Image и Load Symbols, а в поле Initialization Commands добавить file Debug/Test.elf

Создадим конфигурацию для запуска:

Ещё можно удалить лишние кнопки с тулбара.
Меню Window->Customize Perspective…

Проверено в трёх вариантах: ST-LINK + пациент через JTAG, STM32Discovery (через SWD), и ST-LINK + пациент на Discovery через SWD.

Читайте также: