Как проверить прошивку на ошибки - Ремонт и установка крупной бытовой техники

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

0-* Вывод системной частоты наружу

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

    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,},

Потом берем осциллограф, измеряем реальную частоту, сравниваем с настройками в коде, делаем вывод.

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 программы. Стоит поставить одну единственную точку останова и вы уже отлаживаете совершенно не ту программу, которую писали.

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 Toolchain10 2021.10binarm-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 и вы сами увидите как вам понравится такая отладка.

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(нуть) гаджет.

Вывод

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

Общая идея такова, что более высокоуровневые программные компоненты можно отлаживать только менее высокоуровневыми программными компонентами.

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