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

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

Макрос 2:

Рисунок 9: Макрос отладки с отключенными прерываниями

На рис. 10 показана версия предыдущего кода с синхронизацией. Разница здесь в том, что мы используем вывод в качестве тактового сигнала, и после установки отдельных выводов в высокий или низкий уровень мы подаем импульс на вывод тактового сигнала. Полезно использовать, если мы выполняем захват в режиме внешней синхронизации помощью логического анализатора.

Макрос 3:

Рисунок 10: Версия отладочного макроса с тактовой частотой

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

Макрос 4:

Рис. 11. Макрос отладки с запуском по длинному импульсу

На этот раз формирование тактового сигнала чередуется на каждом такте, что облегчает их просмотр в режимах синхронизации или переходных режимах синхронизации. Однако при захвате режима состояния могут возникнуть трудности, поскольку вам потребуется захватывать сигналы на обоих фронтах тактового сигнала; а это не всегда возможно. Обратите внимание, что v_DebugClkState должна быть глобальной переменной для функции отладки.

Отличия в RTOS

В RTOS вам, возможно, придется выводить коды из разных задач. Примерно также, как при обработке прерывания. Необходимо защитить каждый вывод от других задач. Вместо отключения прерываний вы можете вызвать специфичный для ОС вызов, чтобы запретить переключение контекста в течение этого интервала. К сожалению, это может остановить вашу систему на некоторое время. Другой вариант — запускать отладочные коды из самого ядра. Это предоставит системную информацию (т. е. выполнение задач), но не конкретные данные задачи. Другой самый простой способ — отследить одну задачу. Затем вы можете запретить переключение контекста, чтобы иметь более единообразное отображение времени. Конечно, у вас должен быть возможность изменение уровня сигнала на выводе тестового сигнала отлаживаемой задачи. Другой подход может состоять в том, чтобы иметь сервер отладки, который ставит сообщения отладки в очередь и выводит коды во временной последовательности FIFO, возможно с дискриминацией задача/данные. Конечно, это более сложный сценарий.

Шаг 3. Выберите точки отладки и данные в коде

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

Рис. 12. Коды действий отладки для вывода

Рисунок 13: Применение процедуры отладки для определения сброса

В этом примере на рисунке 13 выводятся две переменные v_status1, v_status2. Для того, чтобы понять, когда будут выведены эти коды (очевидно, после перезагрузки, но доступ к этому выводу может оказаться затруднительным), поэтому выбрали код 0x0C (c_DBG_SRST), который с наименьшей вероятностью совпадает с одной из переменных v_status1/2. Кроме того, поскольку необходимо отслеживать две переменные, маловероятно, что все коды будут одинаковыми (0x0C). Таким образом, в тех редких случаях, когда выводился код 0x0C, я знал, что одна из переменных имеет одинаковое значение. Изменение второй переменной обеспечит временную шкалу (тактовый сигнал) выходного кода.

Наличие макроса для функции отладки позволяет выбрать в одном месте кода, какая функция отладки вам понадобится для конкретных тестов.

Шаг 4: Настройка режима сбора данных и выбор соответствующей функции отладки

На этом шаге разберем различные макросы вместе с соответствующими настройками логического анализатора.

Сценарий 1: режим LA: Timing/Macro 1 или 2

Самая простая конфигурация. Вы настраиваете свой логический анализатор в режиме синхронизации и используете макрос 1 или 2 в своем коде. Режим синхронизации очень быстро заполнит доступную память, поэтому следует использовать «умный» запуск для захвата событий вокруг интересующей вас точки. На рис. 14 показан смоделированный пример, показывающий, как логический анализатор будет отображать выходные данные. Допустимые коды действий: 0x06, 0x0B, 0x10.

Рисунок 14: Моделирование захвата Logic Analyzer кодов действий в режиме синхронизации

Как можно заметить, между каждым переходом кода действия есть коды, которые загромождают временную диаграмму. Поэтому необходимо измерить их синхронизацию, чтобы быть уверенным, какие переходы являются действительными кодами, а какие — фантомными кодами, возникающими в результате изменения битов. На рис. 15 можно увидеть переходы битов более подробно. Я показываю шину на уровне битов, чтобы было легче увидеть переходы битов, вызывающие проблемы.

Рисунок 15: Фрагмент рисунка 14, демонтрирующий изменение битов между допустимыми кодами действий.

Как видите, хотя коды действий могут быть жизненно важным инструментом для быстрого решения проблемы, ситуация может потребовать некоторого опыта для определения правильных точек захвата данных.

Сценарий 2: Режим логического анализатора: Переходный/Макрос 1 или 2

В этом режиме у вас будет такая же временная диаграмма, как и выше. Единственная разница будет заключаться в объеме потребления памяти, которое в этом случае будет намного меньше. Заполнение памяти может занять несколько часов, в зависимости от частоты событий. Если ваш LA поддерживает переходный режим, нет особой причины использовать режим синхронизации для отладки программного обеспечения.

Временные и переходные режимы полезны, если вам нужно сопоставить коды программных действий с внешними аппаратными событиями (например, прерываниями, сигналами АЦП или ЦАП). Например, вы можете проследить линию аппаратного прерывания и увидеть корреляцию процедуры обработки прерывания с внешним физическим триггерным сигналом. Вы также можете наблюдать за длительностью вашего обработчика. Кроме того, вы можете изменить макросы 1 или 2 (рис. 8, рис. 9), чтобы обеспечить сигнал проверки. Сигнал будет высоким, если отладочные данные стабилизируются.

Рисунок 16: Проверка кода действия с помощью отдельного сигнала

За счет сигнала у вас есть простой способ определить действительные коды отладки. Здесь, на рисунке 16, сигнал проверки называется LA_DebugClk (вне данных отладки).

Сценарий 3: Режим логического анализа: Состояние/Макрос 3 или 4

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

На рис. 17 показано, как предыдущие примеры будут отображаться в режиме состояния.

Рис. 17. Захват сигнала в режиме состояния с помощью Logic Analyzer

Обратите внимание, что тактовый сигнал всегда имеет высокий уровень, когда вы используете захват нарастающего фронта (обратное верно для спадающего фронта). Это нормально. Если бы вы могли сэмплировать тактовый сигнал как информационный сигнал, в этом случае он всегда был бы высоким. Таким образом, вы никогда не должны видеть, как меняется тактовый сигнал, если вы установили свой логический анализатор в режим состояния. Теперь вы ясно видите, что коды отладки 0x0B, 0x06 и 0x10. Память снова сохраняется, так как записываются только синхронизированные события.

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