Вышла версия 0.4.1 stm32-gdbtest — инструмента для проверки работающей прошивки на физической плате через GDB и SWD-отладчик. Значение выпуска в том, что он собирает в более понятный процесс документацию, локальные проверки и сценарий разработки с обратной связью от устройства. Для команд, которые тестируют firmware не только на хосте, это снижает зависимость от неформальных инструкций и ручной настройки стенда.
Что именно изменилось в 0.4.1.
По данным карточки релиза в GitHub, версия 0.4.1 является документационным выпуском. README стал компактнее: схемы запуска и профили микроконтроллеров вынесены на отдельные страницы. Также появился единый маршрут для локального CI — с описанием снимков исходников, Docker volume в Windows, выбора групп проверок, диагностики задержек и сохранения результатов при ошибках.
Разработчик отдельно указывает, что поведение runner, Target API и backend в 0.4.1 не изменилось. API_VERSION и схема target.toml остаются на версии 2, прочие форматы также не менялись. Поэтому пользователям 0.4.0 не требуется миграция. Это существенное разграничение: новый номер версии не означает новый протокол взаимодействия с платой или необходимость переписывать действующие сценарии.
Граница между возможностями 0.4.0 и документацией 0.4.1.
В сводке изменений stm32-gdbtest описаны возможности, на которые теперь опираются примеры и руководства: исход SKIP с пояснением причины, сохранение записей сценария, экспорт результатов с проверкой целостности артефактов, автономные HTML-отчёты и повторные циклы тестирования из подготовленного комплекта без репозитория приложения на стенде. Упоминаются также backend st-util, доработки удалённого запуска по SSH и новые примеры для событий, интервалов, watchpoint, инъекций и C++.
Эта функциональность не появилась заново в 0.4.1: релиз в GitHub прямо относит пример сценария с профилем запуска, SKIP, чтением полей, записями и табличными проверками к возможностям 0.4.0. Иными словами, 0.4.1 упрощает освоение уже добавленного контура. Для внедрения инструмента это может быть практичнее новой функции: команде легче воспроизвести рекомендуемый запуск и отделить ошибку прошивки от ошибки конфигурации стенда.
Почему HIL-проверки отличаются от обычных тестов.
stm32-gdbtest управляет GDB из Python-сценариев и взаимодействует с платой через SWD, не требуя встраивать тестовый код в прошивку. Такой подход позволяет наблюдать и менять состояние программы в её целевой среде. Как описано в руководстве ArduPilot по отладке STM32, для подключения ST-Link по SWD используются линии SWDIO и SWCLK. Это показывает, что тестовый контур опирается на ту же аппаратную связку, что и низкоуровневая отладка, а не на модель микроконтроллера в памяти компьютера.
GDB в таком контуре выступает не самостоятельным тестовым фреймворком, а каналом наблюдения и управления программой. В документации ST по GDB этот отладчик описан как средство мониторинга исполнения и анализа состояния программы при сбое, в том числе для firmware Cortex-M. stm32-gdbtest использует этот слой для сценарных проверок: тест может ждать событие, отслеживать изменение памяти через watchpoint или фиксировать результаты в артефактах запуска.
Ограничения стенда остаются частью результата.
Аппаратные проверки, приведённые в сводке выпуска, выполнялись на F030, F103, F401, F411, F429 и AT32F403A, в том числе под Windows и на Orange Pi 5. Это не является заявлением о полной совместимости со всем семейством STM32. Для длительных серий на F411 и F030 через ST-LINK GDB Server сохраняется известное ограничение USB ERROR. Командам следует рассматривать результат прогона вместе с данными о плате, отладчике, backend и способе подключения, а не переносить его автоматически на другую конфигурацию.
Аппаратная доступность также влияет на экономику HIL-проверок. В application note AN4989 компании ST сказано, что платы STM32 Nucleo оснащаются встроенным отладчиком-программатором ST-LINK. Для таких плат входной барьер может быть ниже, поскольку отдельный probe не обязателен. Но воспроизводимый CI всё равно требует дисциплины вокруг питания, USB-подключения, состояния платы и сохранения артефактов после сбоев.
Что это даёт разработчикам и AI-агентам.
В 0.4.1 добавлен навык stm32-gdbtest-develop, который формализует цикл «план — исходный FAIL — исправление — регрессия». Его можно применять как инструкцию для человека или AI-агента при подготовке изменений прошивки. При этом навык не заменяет инженерную проверку: агент способен подготовить сценарий и интерпретировать структурированный результат, но достоверность вывода зависит от доступной платы и корректно настроенного стенда.
Главный вывод релиза состоит не в расширении runtime-возможностей, а в закреплении процесса вокруг уже существующих HIL-функций. Пользователям 0.4.0 достаточно обновить документацию и локальные процедуры. При переходе с 0.3.0, согласно опубликованной сводке, потребуется обновить конфигурацию и заменить удалённые методы API. Для команд, которые строят непрерывную проверку firmware, 0.4.1 делает полезнее именно повторяемость запуска, диагностику непригодных сценариев через SKIP и сохранение доказательств результата.
