Комментарии 25
В некоторых «жирных» контроллерах есть скоростной интерфейс ETM Trace, требует более навороченного программатора/отладчика, зато позволяет собирать огромное количество информации о происходящем в контроллере в реальном времени.
Есть еще механизм Semihosting — по интерфейсу SWD можно передавать/принимать данные в терминал.
В многих IDE есть возможность просматривать переменные в реальном времени, не останавливая MCU. Скорость обновления при этом обычно не высокая. Хотя я не уверен, что при этом отладчик не влияет на скорость выполнения программы.
В IAR (про другие IDE не знаю) есть интересная фича — при работающей отладке можно в определённом месте кода сохранить данные из RAM на диск ПК: Ссылка
Для того, чтобы просматривать содержимое массивов в виде графиков при помощи отладчика, я в свое время писал специальную утилиту: Ссылка2
А к какому из вышеперечисленных пунктов относится Посткоды?
》пошаговой отладкой через SWD/JTAG?
На Процессорах она ещё и по каждому из ядер позволяет отлавливать и отлаживать.
Есть еще вариант post-mortem отладки, т.е. снятие дампа памяти, который позже можно как-то расковырять (например, загрузить в отладчик)
И не только памяти, но и регистров периферийных устройств. Этот метод очень полезен при обнаружении аномалий тестировщиками - часто такие аномалии очень трудновоспроизводимы. Я также добавлял функцию "снимок состояния системы" в пользовательский интерфейс, чтобы вылавливать проблемы при пусконаладке и в опытной эксплуатации.
Какой ужас! Мало того, что нет ни эмуляций, ни трассировки в реальном времени (на самом деле есть, но автор просто не знает, как работает упомянутая "хипстерская тулза". Но даже те методы, что описаны, описаны криво!
Чем логи на SD отличаются от логов в USART? Как термометр поможет отлаживать прошивку? Можно было бы добавить примеры вспомогательного кода для отладки. Можно было бы рассказать про дампы памяти на SD и разбор инцидентов. Можно было бы описать ограничения каждого метода и лучшие кейсы применения.
Как правило, методов SWD+логический анализатор хватает для всего. Остальное для совсем уж специфических случаев, а кое что может сожрать весьма существенную часть Flash.
Как правило, методов SWD+логический анализатор хватает для всего.
Пошаговая GDB отладка порой недоступна по той простой причине, что во Flash памяти банально нет места, чтобы зашить *.bin(арь) с ключами, добавляющими отладочные символы (-g3 -ggdb -gdwarf-2 -O0).
Поэтому такую прошивку можно будет отладить разве, что по UART-CLI. Понимаешь?
1) Подмена выходных сигналов отладочной информацией. В той ситуации было совершенно невозможно использовать другие методы отладки. Ни эмулятора, ни точек останова, ни debug printf, ни GPIO/LED. Вместе с тем, прошивка формировала некие выходные сигналы. Временно заменив эти сигналы отладочной информацией, удалось вывести эту информацию наружу и по ней обнаружить и исправить ошибки в программе.
2) Создание эмулятора цифрового датчика. Был создан эмулятор, поддерживающий протокол датчика, но вместо измерения физической величины, он гнал на выход тест-сигналы. Специальным образом подобранные сигналы, рассчитанные на уязвимость алгоритмов их обработки к накоплению ошибок округления, позволили надежно воспроизвести редко возникающий на практике сбой.
3) Опрос регистров причины сброса и вывод их на консоль. Применялось для отладки редко возникающего краха прошивки, приводящего к перезапуску микроконтроллера. Сбивалось раз в сутки или двое, могло без перебоев работать часами. Вывод детальной информации о сбое позволил его несколько локализовать, с последующим выводом более подробной информации и, в конце концов, окончательно отследить и исправить ошибку.
4) Создание «пыточной» программы установления сетевых соединений. Изредка затыкался сетевой стек. Ошибка была практически невоспроизводима «на заказ». С помощью программы, постоянно устанавливающей и рвущей соединения, удалось воспроизвести ошибку за полчаса-час «пыток». Дальше дело техники — внутрисхемный отладчик, останов программы, изучение ее состояния — и вот ошибка найдена и исправлена, повторные несколько суток «пыток» показали, что результат достигнут.
Да, что еще важно… Никогда не отмахиваться от сообщений коллег или клиентов о сбоях. Оно обычно само не проходит, не рассасывается — как беременность.
"Asset"? Может аssert?
STM Studio разочаровало. Работает только через адаптер ST-LINK.
В этом контексте надо было упомянуть о визуальном отладчике в Arduino IDE (раз уж автор выбрал такой хаб).
Нет также упоминаний таких методик как MIL, SIL, PIL, HIL
А это очень интересные подходы.
Как по замерам питания определить, бегает ли контроллер по основной программе, или бесконечно перезагружается из-за ошибки, бесконечно бегает по стёртому флэшу, или завис в бесконечном цикле какого-то обработчика прерывания по-умолчанию? Не говоря уже о том, что просто посмотреть на светодиод гораздо удобнее, чем замерять ток потребления после каждой перепрошивки. Мигающий в норме светодиод нужен не только разработчику, но и эксплуатационному персоналу.
На самом деле наблюдая за током потребления довольно просто определять различные состояния программы, если перед этим вы наблюдали как работает правильная программа.
Вот потребление у некоей схемы при мигающем светодиоде:
Выбросы тока от светодиода очень хорошо видны. На этом фоне видны также выбросы поменьше при обращении к другой периферии на плате. Изучая эти паттерны легко научить обнаруживать ситуации зависания или просто неправильной работы. При зависаниях, скажем, кривая потребления полностью ровная и выше уровнем и т.д.
Но нужен измерительный дивайс с большим динамическим диапазоном.
Который всегда под рукой, особенно в цеху, особенно ночью, особенно за 1000+ километров от офиса разработкии, как вишенка на торте, с системой на проходной "вноси что угодно, но вынести надо пропуск и хрен тебе этот пропуск кто подпишет", да.
Реальная практика которую продавил лично сам:
было на МК 8(восемь) свободных выводов GPIO.
Так совпало что и основных задач выполнения было тоже восемь. А далее было уже преодоление косности мышления коллег и добавление на плату 8 светодиодов и простой строки в тело каждой функции: пока выполняется - горит соответствующий светодиод. Всё.
Любая разработка начинается там, где есть возможность делать диагностику. Когда нет способов диагностики, то говорить о разработке не приходится.
Программировать MK без отладки это как писать ручкой с закрытыми глазами.
В безусловно дельной статье незаслуженно обойден RTT (https://kb.segger.com/RTT). RTT поддерживается SEGGER J-Link и инструментальными средствами от других производителей. Использую RTT для отладки много лет и весьма доволен его возможностями.
16 Способов Отладки и Диагностики FirmWare