Релиз stm32-gdbtest 0.4.1 расширил инструментарий для аппаратного тестирования STM32: теперь результаты сценариев можно сохранять как артефакты, проверять на целостность и просматривать в автономных HTML-отчётах. Для команд, у которых баг проявляется только на реальной плате, это ещё один аргумент переносить часть проверок из ручной отладки в CI.
Проект проверяет уже работающую прошивку на подключённом устройстве: Python-сценарии управляют GDB через SWD-отладчик, а добавлять тестовый код в саму firmware не требуется. О выпуске сообщает Habr / Новости. Такой подход особенно полезен там, где поведение зависит от периферии, таймингов, прерываний или конкретной ревизии железа — то есть почти везде, где классические unit-тесты заканчиваются раньше, чем начинается интересное.
В версии 0.4.1 разработчик дополнил документацию и материалы для AI-агентов, не меняя поведение предыдущего релиза 0.4.0. Основная функциональность появилась именно в 0.4.0: новый выпуск закрепляет её и упрощает внедрение для тех, кто ещё не успел обновиться.
Среди заметных изменений — метод skip(reason). Он позволяет корректно завершить неприменимый к текущей конфигурации сценарий и зафиксировать отдельный результат с причиной пропуска. Это важная мелочь для аппаратного CI: одна и та же тестовая программа может запускаться на нескольких платах, а отсутствие нужной периферии не должно маскироваться под успешное прохождение или необъяснимый сбой.
Также stm32-gdbtest научился хранить произвольные записи, сделанные сценарием, экспортировать результаты и контролировать целостность подготовленных артефактов. В отчётах HTML доступны переключение темы и выбор уровня детализации. Для инженера это означает меньше раскопок в логе после ночного прогона: к результату можно приложить измерения, события и служебные данные именно из той попытки, где устройство повело себя странно.
Отдельно доработан запуск повторных циклов из заранее собранного комплекта. Репозиторий приложения на тестовом стенде для этого больше не нужен. Практический сценарий понятен: сборка и подготовка набора происходят в одном контуре, а стенд с платами получает готовый пакет и выполняет проверки отдельно. Это упрощает эксплуатацию удалённых лабораторий, где доступ к исходникам лишний, а воспроизводимость окружения ценнее удобства разработчика.
В проект добавили backend st-util, обновили схему конфигурации target.toml и переработали удалённый запуск через SSH. Появились примеры для событий, интервалов, ожидания watchpoint, инъекций и C++. В документации есть и единое руководство по локальному CI, включая быстрые проверки в Docker под Windows. Набор выглядит не как очередная обёртка вокруг отладчика, а как попытка описать повторяемый процесс проверки прошивки от рабочей станции до стенда.
Разработчик сообщает о проверках на STM32 F030, F103, F401, F411 и F429, а также AT32F403A. Тестовые запуски выполнялись в Windows, на Orange Pi 5 и в GitHub Hardware CI. При этом сохранено известное ограничение: в длительных сериях для F411 и F030 при использовании ST-LINK GDB Server возможна ошибка USB ERROR. Для команд, которые собираются ставить непрерывные прогоны на ночь или на выходные, это не примечание мелким шрифтом, а риск, который нужно заложить в диагностику стенда.
Переход с версии 0.3.0 потребует обновить конфигурацию и заменить устаревшие удалённые методы API. Это может добавить работы при миграции, но изменения укладываются в логику релиза: аппаратное тестирование STM32 становится полезным только тогда, когда сценарии, плата, отладчик и результаты можно воспроизвести без шаманства одного конкретного инженера.
Интерес к таким инструментам будет расти по мере того, как embedded-команды пытаются приблизить работу с железом к привычкам серверной разработки: воспроизводимым сборкам, артефактам и регрессии на каждом изменении. Главный вопрос теперь не в том, можно ли автоматизировать проверку прошивки на плате, а в том, какую часть реальных отказов удастся превратить в стабильные сценарии до того, как они доедут до производства.