Отладка STM32 через ST-Link и GDB

Введение

В отличие от Arduino, где основным инструментом диагностики обычно служит UART (Serial Monitor), STM32 поддерживает полноценную аппаратную отладку через ST-Link — программатор/отладчик, позволяющий устанавливать точки останова, просматривать содержимое регистров и памяти в реальном времени, без необходимости вставлять отладочный вывод в код. В статье разберём настройку и использование этого значительно более мощного инструментария диагностики.

Концепция

ST-Link — отдельное устройство (встроенное на многих отладочных платах STM32 Discovery/Nucleo, или отдельный внешний программатор) подключается к специальным отладочным пинам микроконтроллера (SWD — Serial Wire Debug, двухпроводной интерфейс) и даёт доступ к OpenOCD (Open On-Chip Debugger) — программному серверу, транслирующему команды стандартного отладчика GDB в низкоуровневые команды управления конкретным микроконтроллером через ST-Link. Этот подход даёт возможности, недоступные через простой UART-вывод — установку точек останова (breakpoints), пошаговое выполнение кода, просмотр и изменение значений переменных и регистров периферии непосредственно во время работы программы на реальном чипе.

Пример кода: Отладка STM32 через ST-Link и GDB

# Установка OpenOCD
sudo apt install openocd

# Запуск OpenOCD-сервера для конкретной отладочной платы (пример для STM32F4 Discovery)
openocd -f interface/stlink.cfg -f target/stm32f4x.cfg

# Подключение GDB к запущенному серверу OpenOCD (в отдельном терминале)
arm-none-eabi-gdb build/Stm32BareMetalDemo.elf

# Команды внутри GDB-сессии:
(gdb) target extended-remote localhost:3333  # подключение к OpenOCD
(gdb) load                                     # загрузка прошивки во flash через ST-Link
(gdb) break main                               # точка останова на функции main
(gdb) continue                                  # запуск выполнения до точки останова
(gdb) next                                      # выполнение следующей строки кода
(gdb) print sensorReadCounter                  # просмотр значения переменной
(gdb) print/x GPIOA->ODR                      # просмотр регистра напрямую, в шестнадцатеричном виде

; launch.json (VS Code) — настройка для отладки через расширение Cortex-Debug,
; объединяющая OpenOCD и GDB в единый, удобный интерфейс отладки внутри IDE
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "STM32 Debug",
            "cwd": "${workspaceFolder}",
            "executable": "build/Stm32BareMetalDemo.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "configFiles": [
                "interface/stlink.cfg",
                "target/stm32f4x.cfg"
            ]
        }
    ]
}

Пояснения к коду

openocd -f interface/stlink.cfg -f target/stm32f4x.cfg запускает сервер, абстрагирующий конкретные детали взаимодействия с ST-Link и конкретной моделью чипа от самого GDB — GDB подключается к этому серверу как к обычному «удалённому» отладочному соединению (target extended-remote), и весь дальнейший процесс отладки (точки останова, просмотр переменных) идентичен по командам GDB-отладке любой другой программы, несмотря на то, что отлаживаемый код выполняется не на той же машине, где работает GDB, а на физическом микроконтроллере. print/x GPIOA->ODR показывает уникальную для embedded-отладки возможность — прямой просмотр содержимого регистров периферии в реальном времени, что даёт возможность точно увидеть текущее аппаратное состояние, а не только значения обычных переменных программы, существенно облегчая диагностику проблем, связанных именно с неправильной конфигурацией периферии.

Подводные камни

Попытка использовать GDB напрямую без запущенного сервера OpenOCD (или аналогичного) — GDB сам по себе не умеет напрямую общаться с ST-Link программатором, и без промежуточного сервера, транслирующего команды, попытка подключения GDB завершится ошибкой соединения; OpenOCD (или альтернативные инструменты, например, встроенный сервер некоторых коммерческих IDE) всегда должен быть запущен и оставаться активным на протяжении всей отладочной сессии.
Установка точки останова внутри обработчика прерывания и попытка отладки в обычном, не специально настроенном для этого режиме, что может существенно изменить тайминг системы (выполнение полностью останавливается на время, пока разработчик изучает состояние в точке останова) — для систем с другими активными прерываниями (например, периодический таймер) остановка выполнения в точке останова может привести к «пропуску» множества тиков таймера, что искажает последующее поведение системы после продолжения выполнения; для отладки тайминг-чувствительного кода иногда полезнее использовать неинтрузивные методы (логирование через UART, аппаратные осциллографы) вместо точек останова, реально останавливающих выполнение всей системы.
Отсутствие соответствия загруженной во flash-память прошивки актуальной версии исходного кода, на который смотрит отладчик GDB при просмотре номеров строк — если прошивка была загружена раньше последней пересборки исходного кода (забытый повторный load в GDB-сессии после изменения кода), GDB будет показывать номера строк и значения переменных, не соответствующие реально выполняющемуся на чипе коду, что приводит к крайне дезориентирующей, неправильной картине происходящего при отладке.
Использование одного и того же ST-Link программатора одновременно с двух разных инструментов (например, OpenOCD из терминала и одновременно отдельная IDE, также пытающаяся подключиться к тому же физическому программатору) — большинство реализаций ST-Link не поддерживают одновременный доступ нескольких независимых клиентов, и попытка такого параллельного доступа обычно приводит к ошибке захвата устройства в одном из конкурирующих инструментов.