Отладка встраиваемых систем (Часть 4)

Если ваш логический анализатор поддерживает режим состояния, то это лучший режим для разработки вашего программного обеспечения. Очень удобно использовать эту настройку, чтобы отслеживать запущенные задачи во встроенной системе и проверять, не были ли пропущены какие-либо сроки. Режим позволяет отслеживать как задержку выполнения, так и продолжительность обработчика. Прерывания или проблемы с многозадачностью.

Что произойдет, если возникнет прерывание, использующее те же макросы в то же время, что и фоновая задача? Если процедура отладки не защищена и активировано прерывание, которое выводит другой код отладки, вы можете пропустить код прерывания или, что еще хуже, у вас может быть поврежден код фоновой задачи. Вот почему у меня есть функции, защищенные от прерываний. Они запрещают прерыванию вмешиваться в выходной код, пока код не будет завершен. Здесь сигнал проверки будет иметь большое значение для идентификации действительных кодов. Для случаев RTOS вам нужно будет добавить функцию вашей ОС, чтобы запретить переключение задач в те же промежутки времени. Вам нужно выполнить это действие, только если вы размещаете отладочный код на многих задачах или прерываниях.

Шаг 5. Выберите подходящее триггерное событие

Когда применяется этот метод вы будете использовать простые триггеры. Однако позже при разработке вам могут потребуются более продвинутые методы работы, чтобы точно локализовать проблему. Например, вы можете оставить LA активным на всю ночь, чтобы зафиксировать пропущенную процедуру или время выполнения задачи, превышающее ограничения. Например, в одном из проектов мы использовали LA для поиска дефекта. В системе, у нас была совместная многозадачность. Каждая задача должна выполняться в течение 2 мс, а затем останавливаться, чтобы разрешить изменение задачи. Настроили триггер для идентификации кода действия, превышающего интервал 2 мс. Установка работала в целевой системе в течение нескольких дней без проблем. Затем однажды мы сделали изменение и сразу же зафиксировали нарушение этого условия. Прежде всего, необходимо как можно точнее определить условия неисправности и то, что отличает ошибочные события от нормальной работы. Эта информация жизненно важна для быстрого поиска проблемы, не полагаясь на «удачу». Если такое условие не уникально, вы можете попытаться поместить коды отладки в свой поток программы, которые сделают события ошибки уникальными, и, таким образом, вы сможете определить соответствующий триггер.

Шаг 6: Запустите систему и соберите данные.

Хорошо, все настроено, и вам нужно только запустить тест. Вам может понадобиться несколько прогонов, чтобы убедиться, что запуск работает хорошо, отображение сигналов в порядке, режим LA настроен правильно и т. д. Не забудьте назначить отладочные метки сигналам шины, чтобы графики были удобочитаемыми (см. рис. 18). Метки могут назначать определенное значение или диапазон значений для метки ASCII. Вместо шестнадцатеричных чисел вы видите соответствующую метку. Если число не совпадает с настройкой метки, вы увидите его как число. Таким образом, неназначенные коды все еще видны. В приведенном ниже примере адресная шина представляет собой код задачи или действия, а шина данных предоставляет значение отладки, специфичное для каждого конкретного события. Таким образом, вы не сможете перепутать вывод, так как каждый вывод данных находится в контексте соответствующего кода действия.

Рисунок 18: Выходные данные логического анализатора после настройки

Также, гистограмма на рис. 19 дает статистическую информацию:

Рисунок 19: Отображение гистограммы логического анализатора

Иногда окно листинга обеспечивает более простой доступ к данным для отладки, более знакомый программистам, как на снимке экрана на рис. 20.

Рис. 20. Отображение перехвата в виде списка обеспечивает более программный вид

Методика отладки с помощью цифрового осциллографа

В этом тестовом примере я опишу отладку с помощью Tektronix MSO2024. MSO представляет собой осциллограф смешанных сигналов. Осциллограф имеет 4 аналоговых канала и 16 цифровых линий. У нас также были модули декодирования RS-232, которые могли использовать как аналоговые, так и цифровые линии. MSO — это инструменты с меньшими затратами по сравнению с логическим анализатором. Также запуск в основном аналогичен тому, что есть у осциллографов. Настройка соединения была такой же, как на рисунке 21.

Рисунок 21: Методика отладки с применением осциллографа

Периодически возникала ошибка неправильного отклика программы. Чтобы решить эту проблему, была развернута тестовая система. Программист изменил версию программного обеспечения и прекратил отправку данных по каналу связи, когда программное обеспечение обнаружило неверный ответ. Тогда последние захваченные данные RS-232 будут стабильны на экране осциллографа. Это было важно, поскольку у MSO не было большого количества памяти или расширенных возможностей запуска. Мы протестировали систему во время работы отладчика, но поведение было другим. Было решено запрограммировать микроконтроллер кодом и посмотреть, как он себя поведет в этом случае. Поведение изменилось! Так что была разница в запуске из отладчика или из самого чипа. Из некоторых подсказок стало понятно, что внутренний сброс может вызвать такое поведение. Поместили пример кода для захвата причины сброса, показанного на рис. 13, в начале и запустил код. MSO зафиксировал данные рисунка 22.

Рисунок 22: MSO в действии; Захват кодов сброса

Захваченные коды указывали на то, что произошел сброс сторожевого таймера. Тайм-аут сторожевого таймера отключен в отладке ISP (по очевидным причинам: вы не можете ставить точки останова или выполнять пошаговые действия, пока работает сторожевой таймер), поэтому я не смог найти эту проблему с помощью обычных методов только для отладчика. Но что было причиной тайм-аута сторожевого таймера? Пробовали запускать до сброса. Активность RS-232 была очевидна, когда возникла проблема. Кроме того, активность отладочного кода останавливается после последнего события Rx, как показано на рис. 23. Здесь пришлось исключить серию циклов «программа-тестирование-замена отладочных кодов», чтобы приблизиться к проблемному коду.

Рис. 23. Последнее событие перед захватом сбоя

При более подробном рассмотрении только события приема было очевидно, что что-то не так в Rx IRQ (процедура обслуживания прерывания). На рис. 24 показано, что было последним действием перед сбоем.

Рис. 24: Последнее событие перед детализацией сбоя. Получение прерываний, а затем система зависает до сброса сторожевого таймера

Затем в следующий момент времени после показанного Rx IRQ произошла ошибка переполнения кадра, обнаруженная IRQ. Однако в данном случае микроконтроллер зацикливался внутри прерывания, что хорошо видно на рисунке 25.

Рисунок 25: Развернутая причина отказа IRQ. Макросы отладки перемещены в подозрительный код.

После проверки кода выяснилось, что проблема заключалась в переменной, которая не была объявлена как volatile. Компилятор оптимизировал чтение регистра, что сбрасывало флаг ожидания прерывания. Кроме того, разница между средой отладки и средой выполнения затрудняет поиск этой ошибки. Обратите также внимание, что найти проблему получилось только в тесном сотрудничестве с программистом (программное обеспечение другого уровня). На диаграмме видно, что на параллельной шине есть переходы сигналов (коды отладки) между допустимыми кодами.

Источник: www.edn.com