В этом тексте перечислены основные способы отлаживать и диагностировать проекты на микроконтроллерах. Для аналогии буду каждому методу отладки метафорично приводить в соответствие аналогию из медицины.
Любая разработка начинается там, где есть возможность делать диагностику. Когда нет способов диагностики, то говорить о разработке не приходится.
Программировать MK без отладки это как писать ручкой с закрытыми глазами.
0-* Вывод системной частоты наружу (быстрый стетоскоп)
В микроконтроллерах STM32 есть один или два пина MCO_1 MCO_2 (Multiplexed Clock-Out) которые позволяют вывести системную частоту поделенную на заданное значение на улицу (за корпус микроконтроллера). В коде это выглядит так
HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSE, RCC_MCODIV_4);
HAL_RCC_MCOConfig(RCC_MCO2, RCC_MCO2SOURCE_SYSCLK, RCC_MCODIV_5);
{.pad.port=PORT_C, .pad.pin=9, .name="MCO_2", .stm_mode=GPIO_MODE_AF_PP, .gpio_pull=GPIO__PULL_AIR, .speed=GPIO_SPEED_FREQ_VERY_HIGH, .alternate= GPIO_AF0_MCO,},
{.pad.port=PORT_A, .pad.pin=8, .name="MCO_1", .stm_mode=GPIO_MODE_AF_PP, .gpio_pull=GPIO__PULL_AIR, .speed=GPIO_SPEED_FREQ_VERY_HIGH, .alternate= GPIO_AF0_MCO,},
Потом берем осциллограф, измеряем реальную частоту, сравниваем с настройками в коде, делаем вывод.
http://dimoon.ru/obuchalka/stm32f1/programmirovanie-stm32-chast-7-vyivod-mco.html
1–*HeartBeat LED (медленный стетоскоп)
Самое важное. Каждое электронное устройство должно иметь хотя бы один светодиод (LED) для того, чтобы пользователь, инженер или техник мог понять, что встроенное firmware вообще вертится и исполняется, а не зависло. HeartBeat LED это своего рода Smoke Test. Если LED не мигает, то тут дальше и говорить не о чем. Сразу очевидно, что прошивка либо не стартовала, либо и вовсе зависла. В случае немигающего LEDа надо подкатывать тяжелую артиллерию. Также желательно ставить отдельно красный LED для индикации ошибки в софте или железе.
HeartBeat LED обычно ставят мигать с частотой 1Hz и, если это в самом деле так, то можно тут же дать гарантию, что тракт подсистемы тактирования тоже корректно настроен.
В общем, господа, делайте всегда HeartBeat LED.
2– Пошаговая отладка GDB через SWD/JTAG (или Хирургическое вмешательство c наркозом или КТ)
В микроконтроллерах есть специальные прерывания, которые позволяют программе останавливаться на заданном адресе (аналогия с анабиозом), который binutils(ами) конвертируется в строку кода в сорцах. Чтобы этим воспользоваться нужно запустить GDB сервер отладки и GDB клиент. Можно остановить программу на конкретной строчке кода.
Однако пошаговая отладка плоха тем, что она нарушает таймингами Real Time программы. Стоит поставить одну единственную точку останова и вы уже отлаживаете совершенно не ту программу, которую писали. Аппаратные таймеру ушли далеко в вперёд. Внешний сторожевой таймер начинает сбрасывать микроконтроллер.
GDB - это как рентгеновская компьютерная томография. Не стоит её делать часто, так как это опасно для здоровья.
13--Утилита arm-none-eabi-addr2line.exe (УльтраЗвуковое Исследование УЗИ)
Если вы поймали HardFault и удалось извлечь значение регистров PC и LR, то можно определить на какой строчке упала прошивка выполнив преобразование адреса в номер строки. Вот такой скрипт
echo off
cls
set ELF_FILE=C:/ncs/v2.1.0/nrf/applications/nrf5340_audio/build/gateway_app/zephyr/zephyr.elf
set ADDR2LINE="C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin\arm-none-eabi-addr2line.exe"
%ADDR2LINE% -e %ELF_FILE% 0x000054cd
%ADDR2LINE% -e %ELF_FILE% 0x0000857e
покажет проблемную строчку в коде.
9– Функции Assert (или ПЦР тест)
Это просто функции, которые выстреливают, когда их аргумент равен нулю.
Есть свой assert на каждую фазу сборки проекта: makeAssert->preprocAssert->staticAssert-> DynamicAssert. StaticAssert отрабатывает на этапе компиляции. Например, что конфиги валидные. DynamicAssert отрабатывает на этапе исполнения. Можно еще расставить как капканы preprocAssert и даже makeAssert, если вы собираете сборку из makefile(ов).
Если сработал DynamicAssert, то можно подключить GDB отладчик и поставить точку останова внутри DynamicAssert. Далее просмотреть стек вызовов и определить причину осечки. В общем пользуйтесь функциями категории assert по-полной.
3– *CLI(шка) (Command Line Interface) (или Компьютерная томография МРТ)
А вот CLI это как раз самый мощный способ отладки прошивок. Как правило CLI терминал это полнодуплексный текстовый интерфейс поверх UART. CLI как способ человеку общаться с прошивкой через понятый обоим сторонам текстовый интерфейс. При этом нужно всего 3 провода (Rx, Tx и GND) и поддержка в коде прошивки. По факту раз запустив CLI и GDB вам уже больше не понадобится. Далее отладка будет только через CLI. Далее вы ограничены одной только своей фантазией в том какие CLI команды добавить в сборку. Можно по команде вычитывать любую память. Можно запускать функции по их адресу в физической памяти. Можно просматривать значения счетчиков, можно пулять пакеты в интерфейсы I2C, SPI, UART. Можно добавить интерпретаторы аппаратных регистров таймеров. Да что угодно.
Важно, чтобы CLI была не просто простыней унылого текста как в NanoVNA V2. В хорошей CLI должно быть: эхо, энергонезависимая история введенных команд, help, TAB-автонабор, авторизация, аутентификация, поддержка цветов, отрисовка таблиц. Это минимальный джентельменский набор взрослой CLI.
Чтобы ошибки отображались красным текстом, предупреждения желтым текстом. Чтобы печатались таблицы для GPIO пинов и каналов ADC.
Также надо различать такие понятия как логирование и CLIшка. При обычном беспонтовом логировании микроконтроллер тупо и отчаянно шлет текст на улицу (в UART). В случае с CLI пользователь может даже сам асинхронно отправить текст в микроконтроллер со стороны улицы. Должна быть установка и отключение логирования для конкретных программных компонентов (например для SPI или ADC), чтобы не было ниагарского водопада из логов, парализующего работу всей прошивки и всякое взаимодействие с программой. CLI не обязательно делать в UART. Подойдет и TCP/UDP, LoRa, BLE-SPP. Просто правда в том, что UART прост как палка и стартует почти сразу после reset(а). Раньше прочих навороченных интерфейсов как TCP стек, а значит и отладить по UART можно будет практически всё.
Причем логировать можно и в RAM память, а отобразить накопившийся лог в UART только после того как проинициализируется подсистема UART (функция flush). Поэтому писать логи можно даже для инициализации подсистемы тактирования, которая отрабатывает до запуска аппаратных драйверов. Достоинство CLI в том, что CLI не нарушает таймингов в той мере, как это делает пошаговая отладка по JTAG/SWD. Вы отлаживаете прошивку "без наркоза". С CLI(шкой) у вас будет тотальный контроль над софтом и железом. Попробуйте запилить CLI и вы сами увидите как вам понравится такая отладка.
https://www.youtube.com/watch?v=ImQ_TO92kGM&t=940s (Начало 14:32)
4– GPIO и осциллограф (Кардиограмма)
В прошивках есть очень быстрые RealTime процессы, которые надо измерять. Как это сделать? А вот так... Можно выставлять напряжение на свободных GPIO пинах и далее смотреть их на экране осциллоскопа. Главное чтобы осциллограф был цифровой так как нужны функции захвата перепадов напряжения. Плюс нужно минимум 2 канала для отладки чего либо нетривиального. Также крайне важно, чтобы осциллограф не гудел как пылесос, иначе не будет никакого желания вообще включать такой оссцилл.
5– GPIO и логический анализатор (Электроэнцефалография)
Более предпочтительным вариантом осциллографу является логический анализатор. У логического анализатора больше каналов (8..16 каналов). Можно анализировать сразу целые много проводные шины (MII, I2S, SDIO). Есть очень хороший логический анализатор Saleae. Подключается к PC по USB 3.0. В отличие от осциллографов логический анализатор абсолютно бесшумный, что позволяет сосредоточится на анализе. Анализ графиков делается прямо на мониторе. Софт рассчитывает периоды, частоты скважность на лету. Также у Saleae очень удобные цепляши.
*6– DAC (Цифро-Аналоговый Преобразователь) (или микроскоп)
Когда GPIO не хватает, то можно выставлять аналоговое напряжение на одном DAC пине и тоже смотреть осциллографом с достаточным разрешением. В большинстве адекватных MCU(шек) всегда есть встроенный 10...12бит ЦАП для таких случаев. Очень удобно при отладке планировщиков многопоточных прошивок. По ступеням напряжения на выходе ЦАП можно определить реальный приоритет потоков.
7– Логирование на дисплей (Глюкометр)
В принципе, если есть достаточно пинов, то для автономности отладки можно поставить какой-нибудь дисплей и отображать на нем важные метрики софта. Получится устройство тамагочи, которое само все про себя расскажет своему хозяину. Советую смотреть в сторону OLED экранов так как у OLED светятся символы, а не фон. Выглядит футуристично и очень приятно читать.
8– Модульные тесты (скрепы / гипс)
Часто возникает ситуация когда есть большой кусок кода и нет возможности пройти этот код отладчиком. Например времени мало. В этом случае можно просто покрыть этот код тестами. Также тесты позволят без опаски совершать перестройку софта. Тесты будут стимулировать вас писать более модульный и качественный код.
10– STMStudio (Электроэнцефалография)
У ST есть хипстерская Tool(а), которая позволяет по SWD/JTAG следить за конкретными переменными в физической памяти (REG, RAM, ROM) микроконтроллера.
Просто скармливаешь STMStudio *.map файл и подключаешь по SWD Target. Причем эта Tool(а) позволяет строить графики по значениями переменных в памяти. Это как утилита ArtMoney в случае с взломом компьютерных игр на PC, только для микроконтроллера. STMStudio мега удобна при отладке систем автоматического управления (ПИД ругуляторы), цифровых фильтров, триггеров Шмитта и прочей DSP обработки. Меняя значения переменных можно даже управлять поведением прошивки!
Все бы вендоры микроконтроллеров выпускали бы такие шедевральные утилиты для своих чипов как STMStudio для STM32 микроконтроллеров.
11– Логирование в SD карту (Копрограмма)
UART это весьма медленный интерфейс. Максимум 1 МBit/s. Поэтому отладка логированием в UART всё же немного, но нарушает тайминги, а значит и логику работы устройства. Если быстродействие гаджета критично, а логи тоже очень нужны, то логи можно записывать в какие-нибудь число хранилище. Например SD карту или OffChip SPI-NorFlash на несколько мегабайт. Там 25MHz это норма. Однако придется собрать файловую систему (например FatFs) на SD карте, чтобы потом можно было писать в настоящие файлы и читать их на LapTop. Затем в период Idle выгрузить логи в тот же самый UART или TCP/UDP. Easy.
12– Health Monitor (Мед брат)
Health Monitor (HM) просто поток или отдельная периодическая функция, которая только лишь регулярно проверяет критические параметры прошивки. Своего рода периодические модульные тесты. HM проверяет, например, что UART и CLI не упала. Что есть всяческие Link(и) c I2C, SPI чипами. Что напряжение не просело. Плюс Health Monitor(а) в том, что если что-то внезапно рухнет (например от заряженной частицы из космоса), то прошивка об этом узнает сразу и что-нибудь да предпримет. Health Monitor обладает правами выполнить какой-то мелкий ремонт: переинициализировать отдельный компонент, что-нибудь починить или и вовсе Reset(нуть) гаджет.
13-- Эмуляция прошивки как процесса на PC (клонирование)
Если у вас в прошивке есть CLI, то вы можете собрать прошивку прямо на nettop x86. Прошивку можно запустить на исполнение как консольное приложение в командой строке cmd. Затем исполняя команды в stdin и наблюдая за выводом в stdout вы можете отладить огромные куски кода, которым всё равно на архитектуру. Протестировать реализацию протоколов, математику, аллокатор памяти, криптографию, fifo lifo циклический буфер, алгоритмы расчета контрольных сумм, шрифты графических экранчиков, триггер Шмитта, распознаватели строчек и многое друге что не зависит от архитектуры.
14-- DMM цифровой мультиметр (градусник)
DMM можно проверить самые базовые параметры электронной платы: напряжение питания на разных рельсах, частоту PWM на LED(ах), прозвонить пины, измерить постоянные ток.
15--Контроль качества пайки (Load-detect)
Идея очень проста. Надо выбрать конкретный пин, пробежаться по всем трём подтяжкам напряжения, в каждой подтяжке прочитать и запомнить логическое состояние пина на GPIO. Затем найти в подсказке строчку которая и скажет, что подключено к пину со стороны улицы.
Подробнее про это тут https://habr.com/ru/articles/756572/
Вывод
Как видите во встраиваемом софте есть целая куча способов отлаживать код и железо. Конечно тут не все зависит только от программиста. Некоторые опции отладки требуют и от разработчика HardWare некоторых предварительных телодвижений (добавить LED(ы), UART, TestPad(ы), Flash, SWD разъем). Что вы возьмете на вооружение решать вам. Мне же для отладки в 99% случаев хватает Assert, LED, CLI, HM, uTests.
Общая идея такова, что более высокоуровневые программные компоненты можно отлаживать только менее высокоуровневыми программными компонентами.
Если вам известны еще оригинальные способы отлаживать Embedded Software/Firmware, то пишите их в комментарии.
Акроним | Расшифровка |
MCO | Multiplexed Clock-Out |
Links
https://we.easyelectronics.ru/CADSoft/mcucapture---utilita-dlya-zahvata-dannyh-iz-massiva-v-pamyati-mikrokontrollera.html
https://habr.com/ru/articles/694408/
https://habr.com/ru/articles/698092/
https://habr.com/ru/articles/682498/
https://habr.com/ru/articles/698572/
https://habr.com/ru/articles/694708/
https://habr.com/ru/articles/655641/
https://www.youtube.com/watch?v=ImQ_TO92kGM&t=940s (Начало 14:32)
http://dimoon.ru/obuchalka/stm32f1/programmirovanie-stm32-chast-7-vyivod-mco.html