13 Способов Отладки и Диагностики FirmWare

В этом тексте перечислены основные способы отлаживать и диагностировать проекты на микроконтроллерах. Для аналогии буду каждому методу отладки приводить в соответствие аналогию из медицины

1–*HeartBeat LED (Стетоскоп)

Самое важное. Каждое электронное устройство должно иметь хотя бы один светодиод LED для того, чтобы пользователь, инженер или техник мог понять, что встроенное firmware вообще вертится и исполняется, а не зависло. Если LED не мигает, то тут сразу очевидно, что прошивка либо не стартовала, либо и вовсе зависла. В случае немигающего LED  надо подкатывать тяжелую артиллерию. Также желательно ставить отдельно красный LED для индикации ошибки в софте или железе.

2– Пошаговая отладка GDB через SWD/JTAG (или Хирургическое вмешательство c наркозом)

В микроконтроллерах есть специальные прерывания, которые позволяют программе останавливаться на заданном адресе (аналогия с анабиозом), который binutils (ами) конвертируется в строку кода в сорцах. Чтобы этим воспользоваться нужно запустить GDB сервер отладки и GDB клиент. Можно остановить программу на конкретной строчке кода.

61ca4bde9739aae51dd6fc5a1d96b52e.png

Однако пошаговая отладка плоха тем, что она нарушает таймингами Real Time программы. Стоит поставить одну единственную точку останова и вы уже отлаживаете совершенно не ту программу, которую писали.

9– Функции Asset (или ПЦР тест)

Это просто функции, которые выстреливают, когда их аргумент равен нулю. 

Есть свой assert на каждую фазу сборки проекта: make_assert→preproc_asset→static_asset→ DynamicAsset. Static_asset  отрабатывает на этапе компиляции. Например, что конфиги валидные. Dynamic_asset отрабатывает на этапе исполнения. Можно еще расставить как капканы preproc_asset и даже make_assert, если вы собираете сборку из makefile (ов).
Если сработал DynamicAsset, то можно подключить GDB отладчик и поставить точку останова внутри DynamicAsset. Далее просмотреть стек вызовов и определить причину осечки. В общем пользуйтесь функциями категории asset по-полной.

3– *CLI (шка) (Command Line Interface) (или Компьютерная томография)

А вот CLI это как раз самый мощный способ отладки прошивок. Это текстовый интерфейс поверх UART. CLI как способ человеку общаться с прошивкой через понятый обоим сторонам текстовый интерфейс. При этом нужно всего 3 провода (Rx, Tx и GND). По факту раз запустив CLI и GDB вам уже больше не понадобится. Далее отладка будет только через CLI. Вы ограничены только своей фантазией в том какие CLI команды добавить в сборку. Можно по команде вычитывать память. Можно запускать функции по их адресу в памяти. Можно просматривать значения счетчиков, можно пулять пакеты в интерфейсы I2C, SPI, UART.

Важно, чтобы CLI была не просто простыней унылого текста. В CLI должна быть поддержка ASCII графики и цветов.

bc297fb8d9126d0804a63aed703a170f.png

Чтобы ошибки отображались красным текстом, предупреждения желтым текстом. Чтобы печатались таблицы для GPIO пинов и каналов ADC.

905c9a861d968e6f39d81c69ddf6aed5.JPG

Также надо разделять такие понятия как логирование и CLIшка. При обычном беспонтовом логировании микроконтроллер только и шлет текст на улицу (в UART). В случае с CLI пользователь может даже сам асинхронно отправить текст в микроконтроллер со стороны улицы (в UART). Должна быть установка и отключение логирования для конкретных программных компонентов, чтобы не было ниагарского водопада из логов, парализующего работу всей прошивки и всякое взаимодействие с программой. CLI не обязательно делать в UART. Подойдет и TCP/UDP, LoRa, BLE-SPP. Просто UART прост как палка и стартует почти сразу после reset (а). Раньше прочих интерфейсов как TCP IP стек, а значит и отладить по UART можно будет практически всё.

Причем логировать можно в RAM память, а отобразить накопившийся лог в UART только после того как проинициализируется подсистема UART (функция flush). Поэтому писать логи можно и для инициализации подсистемы тактирования, которая отрабатывает до запуска драйвера UART. Достоинство CLI в том, что CLI не нарушает таймингов в той мере,   как это делает пошаговая отладка по JTAG. Вы отлаживаете прошивку «без наркоза». С CLI (шкой) у вас будет тотальный контроль на прошивкой.

4– GPIO и осциллограф (Кардиограмма)

Есть очень быстрые процессы, которые надо измерять. Можно выставлять напряжение на GPIO пинах и далее смотреть их на экране осциллоскопа. Главное чтобы осциллограф был цифровой так как нужны функции захвата перепадов напряжения. Плюс нужно минимум 2 канала для отладки чего либо нетривиального. Также крайне важно, чтобы осциллограф не гудел как пылесос, иначе не будет никакого желания вообще включать такой оссцилл.

5– GPIO и логический анализатор (Электроэнцефалография)

Более предпочтительным вариантом осциллографу является логический анализатор. У логического анализатора больше пинов (8…16 каналов). Можно анализировать сразу целые много проводные шины (MII, I2S, SDIO). Есть очень хороший логический анализатор Saleae. Подключается к PC по USB 3.0. В отличие от осциллографов логический анализатор абсолютно бесшумный, что позволяет сосредоточится на анализе. Анализ графиков делается прямо на мониторе. Софт рассчитывает периоды, частоты скважность на лету. Также у Saleae очень удобные цепляши.

2f47db0ddb976aed07e81a26a1739cd5.png

*6– DAC (Цифро-Аналоговый Преобразователь) (или микроскоп)

Когда GPIO не хватает, то можно выставлять аналоговое напряжение на одном пине и тоже смотреть осциллографом с достаточным разрешением. В большинстве адекватных MCU (шек) всегда есть встроенный 12 бит ЦАП для таких вещей. Очень удобно при отладке планировщиков многопоточных прошивок. По ступеням напряжения на выходе ЦАП можно определить реальный приоритет потоков. 

7– Логирование на OLED экран (Глюкометр)

В принципе, если есть достаточно пинов, для автономности отладки можно поставить какой-нибудь дисплей и отображать на нем какие-то метрики софта. Получится устройство тамагочи, которое самое все про себя расскажет своему хозяину.

8– Модульные тесты (скрепы)

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

10– STMStudio (Электроэнцефалография)

У ST есть хипстерская Tool (а), которая позволяет следить за конкретными переменными в RAM\REG\ROM памяти микроконтроллера. 

7eaef3328ed6ec9c54a5c715ca036f98.jpeg

Просто скармливаешь ей *.map файл. Причем эта Tool (а) позволяет строить графики по значениями этих переменных. Это мега удобно при отладке систем автоматического управления, цифровых фильтров и прочей DSP обработки. Все бы вендоры микроконтроллеров выпускали бы такие утилиты для своих чипов как STMStudio для STM32.

11– Логирование в SD карту (Черный ящик)

UART это весьма медленный интерфейс. Максимум 1 МBit/s. Поэтому отладка логированием в UART всё же немного, но нарушает тайминги, а значит и логику работы устройства. Если быстродействие гаджета критично, а логи тоже очень нужны, то логи можно записывать в какие-нибудь число хранилище. Например SD карту. Там 25MHz это норма. Однако придется собрать файловую систему (например FatFs) на SD карте, чтобы потом можно было писать в настоящие файлы и читать их на LapTop. Затем в период Idle выгрузить логи в тот же UART или UPD. 

12– Health Monitor (Мед брат)

Health Monitor (HM) просто поток или отдельная периодическая функция, которая только лишь проверяет критические параметры прошивки. Своего рода периодические модульные тесты. HM проверяет, что UART и CLI не упала. Что есть всяческие Link (и) c I2C, SPI чипами. Что напряжение не просело. Плюс Health Monitor (а) в том, что если что-то внезапно рухнет (например от заряженной частицы из космоса), то прошивка об этом узнает сразу и что-нибудь предпримет. Health Monitor обладает правами выполнить какой-то мелкий ремонт: переинициализировать отдельный компонент, что-нибудь починить или и вовсе Reset (нуть)  гаджет.

13– Тепловизор (Градусник)

Когда плата где-то коротит, то самый простой способ найти место короткого замыкания это тепловизор.

Вывод.

Как видите во встраиваемом софте есть целая куча способов отлаживать код и железо. Конечно тут не все зависит только от программиста. Некоторые опции отладки требуют и от разработчика HardWare некоторых предварительных телодвижений (добавить LED (ы), UART, TestPad (ы), Flash, SWD разъем). 

Если вам известны еще оригинальные способы отлаживать Embedded Software, то пишите их в комментарии.

© Habrahabr.ru