что такое отладочный интерфейс

JTAG в каждый дом: полный доступ через USB

Исследователи Positive Technologies активировали аппаратную отладку (JTAG) для Intel Management Engine, которая позволяет получить полный доступ ко всем устройствам PCH (Platform Controller Hub), используя технологию Intel DCI (через интерфейс USB). Мы планируем поделиться подробностями на одной из ближайших конференций. А о том, как активировать этот интерфейс, но для основного процессора, расскажем ниже.

От ошибок никто не застрахован. Это утверждение касается и низкоуровневого программирования, где таких привычных средств, как отладочная печать или программный отладчик, в определенный момент может быть уже недостаточно. Для решения этой проблемы разработчики аппаратных средств используют так называемые внутрисхемные эмуляторы (in-circuit emulators) или специальный отладочный интерфейс JTAG, если он присутствует на целевой платформе (IEEE1149.1 [1]). Эти отладочные механизмы появились еще в 80-х годах прошлого века [2]. Со временем производители микросхем расширяли возможности этих интерфейсов. Благодаря этому разработчики смогли получать детальную информацию об энергопотреблении, находить узкие места в высокопроизводительных алгоритмах и получили много других возможностей.

Для исследователей безопасности аппаратные средства отладки также представляют интерес. Они позволяют получить низкоуровневый доступ к системе в обход основных средств обеспечения безопасности, изучать поведение целевой платформы и ее недокументированные возможности. Очевидно, что подобные возможности оказались привлекательны и для спецслужб [3].

Долгое время доступ к этим технологиям для процессоров Intel имелся только у ограниченного круга лиц, что было связанно с необходимостью использования дорогого специализированного оборудования. Но с выходом процессоров семейства Skylake ситуация кардинально изменилась: отладочные механизмы были встроены в PCH [4], что позволяет использовать столь мощный инструмент обычным пользователям — включая и злоумышленников, которые могут таким образом получить полный контроль над процессором. Из соображений безопасности по умолчанию эти механизмы не активированы, но в данной статье мы покажем, что их можно заставить работать на оборудовании, которое доступно в обычных компьютерных магазинах.

Эволюция отладочных средств на процессорах Intel

1. От in-circuit emulator к JTAG

Первоначально in-circuit emulator (ICE) для процессоров Intel 80286 представлял собой отдельный компьютер («большую синюю коробку» [5]), который включал клавиатуру и монитор. ICE подключался вместо процессора отлаживаемой системы и эмулировал его поведение. Такой эмулятор позволял устанавливать точки останова, изменять память и регистры процессора, производить запись и чтение.

Позднее Intel представила новый аппаратный отладчик I2ICE (рис. 1), который уже не заменял собой штатный процессор. С помощью специальных переходников пользователь подключался к отлаживаемой системе, а для общения с хост-машиной такой аппаратный отладчик использовал стандартный последовательный порт на скорости 9600 Бод [5].

Рис. 1. Intel I2ICE — один из первых внутрисхемных отладчиков для процессоров Intel 80386 (recycledgoods.com/intel-series-iv-emul-system-iii514b.html)

По мере развития технологий и увеличения тактовых частот Intel отказывается от разработки отдельных полнофункциональных средств отладки и частично переносит ее внутрь процессора, в виде специального недокументированного режима ICE-mode (который по принципам работы очень напоминал другой режим — System Management Mode (SMM), у некоторых разработчиков того времени было стойкое убеждение, что SMM — не что иное, как документированный и расширенный ICE-mode [6]). В свою очередь, всеобщая стандартизация отладочных механизмов в электронной промышленности приводит к тому, что в некоторых процессорах Intel 80486 появляется поддержка тестового интерфейса IEEE1149.1 (JTAG) [7].

Joint Test Action Group (JTAG) на самом деле является названием рабочей группы, которая разработала стандарт Standard Test Access Port and Boundary-Scan Architecture (IEEE1149.1 [1]). Он позволяет использовать стандартную аппаратуру тестирования и отладки для широкого класса устройств. Со временем сокращение JTAG стало ассоциироваться со стандартом IEEE1149. В современных микросхемах он широко распространен в промышленности и используется для тестирования, прошивки, отладки и выходного контроля микросхем при производстве. Физически JTAG представляет собой четыре или пять выделенных линий, которые образуют тестовый порт TAP (Test Access Port). Стандарт предусматривает объединение устройств в цепочку, позволяя получать доступ к каждому подключенному устройству (рис. 2).

Рис. 2. Объединение отлаживаемых устройств в JTAG-цепочку

Часто разработчики аппаратуры расширяют базовую функциональность JTAG, вводя новые возможности; процессоры Intel не стали в этом смысле исключением, начиная с Pentium появляется более дешевый и мощный вариант внешнего отладчика, который использует специальный зондовый режим (probe mode).

2. Режим зондовой отладки

Режим зондовой отладки (probe mode) является еще одним недокументированным режимом работы процессоров Intel. Он используется для диагностики и отладки. Его невозможно активировать без доступа к JTAG-регистрам процессора. В probe mode процессор может изменять память, производить запись и чтение из портов ввода-вывода. В данном режиме прерывается нормальное выполнение инструкций и процессор переходит в режим бездействия, ожидая команд по интерфейсу JTAG. Такое поведение принципиально отличает данный механизм от ICE-mode, когда инструкции на процессоре продолжали выполняться. При входе в probe mode останавливается предварительная выборка и декодирование команд. Команды от JTAG для модификации или чтения поступают непосредственно в исполнительные блоки процессора, тем самым минуя этапы предварительной выборки и декодирования [8], что позволяет получать доступ к ряду регистров, которые недоступны из обычных режимов.

Probe mode реализован как расширение JTAG с добавлением нескольких регистров и дополнительных сигналов R/S#, PRDY (подробнее о том, как реализован режим probe mode, см. [8], [9]). Сторонние компании наравне с Intel выпускают JTAG-адаптеры для процессоров x86, в которых обеспечивается поддержка этого расширения, но мы рассмотрим только оригинальные аппаратные средства отладки.

3. Современные аппаратные средства и технологии отладки процессоров Intel

Современные процессоры Intel предоставляют JTAG через три интерфейса:

Рис. 4. Типы подключения DCI

Рис 5. Intel SVT Closed Chassis Adapter

Интерфейс Intel ITP-XDP имеет закрытый протокол, требует специализированного разъема на плате и специализированного программного обеспечения Intel System Studio (на сайте производителя доступна пробная версия). К недостаткам также стоит отнести высокую цену (около 3000 долларов США) и необходимость подписывать документы о неразглашении информации (Corporate Non-Disclosure Agreement) [10]. Высокая цена и CNDA делают данный отладчик недоступным для рядового разработчика или домашнего использования.

Однако начиная с процессоров семейства Skylake Intel внедрил технологию Direct Connect Interface (DCI), ее достаточно поверхностное описание можно найти в документации [4]. Данная технология ставит своей целью упростить разработку мобильных устройств, из чего вытекает ее недостаток: ее можно активировать без каких-либо аппаратных модификаций (при наличии JTAG линий между PCH и CPU). Также стоит отметить, что подключение с использованием адаптера Intel SVT использует линии USB 3.0, но реализует свой протокол, что позволяет работать с целевой системой в режимах глубокого сна. К сожалению, адаптер SVT при своей относительно низкой цене (390 долларов США) также доступен для покупки только после подписания CNDA.

Самым интересным для рядового программиста вариантом, который при этом не требует подписания каких-либо документов перед использованием, является USB3 Hosting DCI. Он представляет JTAG-интерфейс через обычный отладочный кабель USB 3.0. При активации DCI на целевой системе порт USB 3.0 переходит в режим slave и начинает принимать команды от хостовой системы.

Один из важных вопросов относительно USB 3.0 DbC DCI Hosting заключается в том, через любой ли внешний порт USB 3.0 возможно подключение к DCI — или требуется отладочный порт, доступный только на специальных системных платах для разработчиков. Следует рассмотреть данный вопрос подробнее.

В среде системных разработчиков существует путаница, порожденная тем, что сама по себе отладка через USB появилась достаточно давно (со времен USB 2.0) и в данный момент используется многими разработчиками для программной отладки ядер операционных систем и UEFI приложений. Однако программная отладка через USB (в windbg, UEFI debug agent и т. п.) не имеет ничего общего с механизмами аппаратной отладки через JTAG, кроме собственно транспорта. Спецификация контроллера шины USB 2.0 (EHCI, Enhanced Host Controller Interface) предоставляет специальный механизм, который называется Debug Port (PCI capability), с помощью которого возможно взаимодействие между сервером (программным или аппаратным) на отлаживаемой машине и клиентом на хосте. В частности, ядро Windows поддерживает отладку через EHCI Debug Port (при этом нужен отладочный кабель USB 2.0, с интегрированным устройством USB 2.0). При этом, действительно, не каждый внешний порт USB 2.0 мог работать как Debug Port, а эта возможность была закреплена за определенными портами, которые могли быть и не выведены наружу. Все зависело от производителя оборудования. Поэтому разработчики специально искали оборудование с выведенным наружу Debug Port, для отладки по USB. Таким образом, Debug Port — это атрибут USB-порта.

Однако ситуация полностью изменилась с появлением USB 3.0 и спецификации контроллера этой шины XHCI (eXtended Host Controller Interface). Данная спецификация также поддерживает отладку по USB, однако она претерпела существенное развитие и стала называться USB Debug Capability (DbC). Согласно XHCI, DbC является не атрибутом порта, а свойством конкретного контроллера XHCI. То есть, если данный XHCI-контроллер поддерживает DbC, то возможность отладки по USB 3.0 будет доступна на любом (в том числе и внешнем) порте USB 3.0. При этом DbC автоматический выберет первый порт, к которому подключен отладочным кабелем клиент, выполняющий транзакции USB 3.0.

Здесь важно отметить, что первые XHCI-контроллеры не поддерживали DbC, поэтому на системах с такими котроллерами отладка по USB была невозможна. Однако в PCH версии 100 и выше (для Skylake) компания Intel встроила свой собственный контроллер XHCI, который поддерживает DbC. Технология Intel DCI (которая и появилась начиная с процессоров Skylake) использует USB 3.0 DbС в качестве транспорта, для подключения JTAG-клиента. USB 2.0 Debug Port он не использует.

Таким образом, через любой порт USB 3.0 можно подключиться к DCI и осуществлять JTAG-отладку.

Активация DCI

Как же можно активировать этот отладочный интерфейс? Мы нашли три способа:

1. Активация через EFI Human Interface Infrastructure

EFI Human Interface Infrastructure — специальный механизм, который позволяет создавать пользовательский интерфейс в UEFI, обрабатывать и контролировать пользовательский ввод. Если посмотреть строение современных UEFI BIOS, можно найти в них множество скрытых опций, которые недоступны пользователю, но обрабатываются. На этом и основан наш первый способ. EFI HII определяет значения по умолчанию для всех опций, в том числе и скрытых. Найдя опцию, связанную с DCI, можно ее активировать для настройки по умолчанию, а затем, установив в BIOS заводские настройки, активировать DCI. Отредактировать эти настройки позволяет утилита AMI BIOS Configuration Program 5.0. Отредактированный образ программируется в SPI-flash программатором или через штатный механизм прошивки BIOS, если позволяют права доступа.

Однако у этого способа есть недостаток: система не загрузится, если активирован Boot Guard, так как утилита изменяет модуль EFI.

2. Активация через Flash Descriptor Region

DCI также можно активировать через настройку специальных битов конфигурации PCH — либо вручную (они находятся в Flash Descriptor Region), либо c помощью утилиты Flash Image Tool. Данный способ работает даже при включенном Boot Guard.

3. Активация через P2SB-устройство

В конце концов, можно попробовать действовать напрямую — через устройство P2SB. В документации на разные поколения PCH можно найти специальный индекс и регистр, используя который можно активировать DCI на лету, если BIOS не заблокировал изменение настройки DCI.

Данный способ является уязвимостью, так как если BIOS не блокирует запись в регистр ECTRL, то из-за особенностей работы (возможности сохранения конфигурации между перезагрузками после выключения питания) позволяет активировать DCI один раз, а далее использовать JTAG-интерфейс как аппаратный backdoor в систему (например, отключать экран блокировки).
Мы провели исследование [12], в результате которого выяснилось, что крупнейшие производители материнских плат не устанавливают блокировку данного регистра, что позволяет активировать DCI и использовать этот механизм, например, для перезаписи BIOS в обход всех средств защиты, включая проверку цифровой подписи.

Резюме

Наличие отладочных механизмов в современных процессорах Intel позволяет облегчить разработку модулей UEFI, операционных систем, гипервизоров. Исследователи безопасности получают низкоуровневый механизм привилегированного доступа к аппаратуре, который может быть использован для поиска зловредного ПО, исследования недокументированных возможностей аппаратуры или драйверов специфического оборудования. Но, как любой отладочный механизм, DCI может использоваться и злоумышленниками для несанкционированного доступа к данным.

В качестве защиты от таких атак мы рекомендуем активировать Boot Guard, проверять бит активации DCI и запрет отладки в регистре IA32_DEBUG_INTERFACE (при этом DCI может работать, но остановить выполнение уже нельзя, поэтому нет возможности получить доступ к памяти и регистрам).

Источник

Русские Блоги

Кратко опишите различия между различными интерфейсами отладки (SWD, JTAG, JLink, ULink, STLink)

Эта статья перепечатывается в блогеleon1741, Щелкните здесь, чтобы перейти к блогу оригинального автора

Я полжизни занимался разработкой встраиваемых систем и ARM. Программа отладкиНеизбежноиз. Я имел дело со многими спецификациями отладки, инструментами отладки и методами отладки, но взаимосвязь между ними не особенно ясна. Давайте взглянем сегодня:

Протокол JTAG

Когда был определен протокол JTAG, поскольку компьютеры (ПК) в то время обычно имели параллельные порты, используемый параллельный порт был определен при подключении к компьютеру. Сегодня компьютеры, не говоря уже о ноутбуках, сейчас на настольных компьютерах очень мало параллельных портов.Замени этоПортов USB становится все больше. Поэтому его редко можно увидеть на рынке.

SWD интерфейс

Последовательную отладку (Serial Wire Debug) следует рассматривать как режим отладки, отличный от JTAG, и используемый протокол отладки также должен отличаться, поэтому он наиболее непосредственно отражается в интерфейсе отладки. По сравнению с 20 выводами JTAG, SWD требует только 4 (или 5) контактов, и структура проста, но сфера применения не такая широкая, как JTAG.Основной отладчик также является режимом отладки SWD, добавленным позже.

Отличие SWD от традиционных методов отладки:

RDI интерфейс

Эмулятор JLink

Эмулятор ULink

Эмулятор ST-Link

ST-LINK специально дляSTMicroelectronicsЭмулятор для микросхем серий STM8 и STM32. Основные функции стандартного интерфейса SWIM и стандартного интерфейса JTAG / SWD, указанного в ST-LINK / V2:

Источник

Отладочный интерфейс

В данном разделе приведено описание отладочного интерфейса процессора ARM7TDMI в следующей последовательности:

В разделе также описывается модуль эмуляции EmbeddedICE, который входит в состав процессора ARM7TDMI, в следующих параграфах:

1. Общие сведения об отладочном интерфейсе

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

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

Запрос, поступивший через один из сигналов интерфейса отладки или внутренний функциональный блок, именуемый логикой эмуляции EmbeddedICE Logic, переводит процессор ARM7TDMI в состояние отладки. Ниже приведены события, которые активизируют отладку:

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

Ядро ARM7TDMI использует два сигнала синхронизации:

В нормальном режиме работы ядро тактируется сигналом MCLK, а внутренняя логика удерживает DCLK в низком состоянии.

Если процессор ARM7TDMI находится в состоянии отладки, то ядро синхронизируется DCLK под управлением цифрового автомата TAP-контроллера, а MCLK может работать вхолостую. Выбранный сигнал синхронизации присутствует на выходе внешней синхронизации ECLK для использования внешней системой.

Прим.: nWAIT не оказывает должного влияния, если ядро ЦПУ находится в состоянии отладки и тактируется сигналом DCLK.

2. Отладочные системы

На рисунке 5.1 показана типичная отладочная система с использованием ядра ARM.

Рисунок 5.1. Типичная отладочная система

Отладочная система обычно состоит из трех частей:

Отладчик и преобразователь протокола являются системно-зависимыми.

В качестве отладчика выступает компьютер, на котором запущена отладочная программа, например, ARM Debugger for Windows (ADW). Отладчик позволяет вводить такие команды высокого уровня, как установка точки прерывания или проверка содержимого памяти.

2.2 Преобразователь протокола

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

Как правило, подключение к компьютеру выполняется через расширенный параллельный порт (ЕРР).

Процессор ARM7TDMI содержит аппаратные расширения, которые упрощают отладку на самом низком уровне. Отладочные расширения:

2.3 Отлаживаемое целевое устройство

Основные блоки отлаживаемого целевого устройства показаны на рисунке 5.2.

Рисунок 5.2. Блок-схема ARM7TDMI

Ядро содержит аппаратную часть, поддерживающая отладку.

Это набор регистров и компараторов, используемых для генерации отладочных исключительных ситуаций, как, например, точки прерывания. Описание этого блока приведено в параграфе «Общие сведения о логике эмуляции EmbeddedICE».

ТАР-контроллер управляет действием цепей сканирования через последовательный интерфейс JTAG.

3. Сигналы интерфейса отладки

Отладочный интерфейс состоит из трех основных внешних сигналов:

Прим.: Для полного разрешения отладочных функций процессора DBGEN необходимо перевести в высокое состояние. См. «Отключение EmbeddedICE».

3.1 Переход в состояние отладки

Процессор ARM7TDMI переходит в состояние отладки после запроса со стороны точек прерывания или точек наблюдения, а также при запросе отладки. Для программирования условий активизации точек прерывания или точек наблюдения необходимо использовать логику EmbeddedICE. Альтернативно, вы можете использовать сигнал BREAKPT, который позволяет внешней логике устанавливать точки прерывания или точки наблюдения, а также контролировать:

Временная диаграмма аналогична внешне-сгенерированным точкам прерывания и наблюдения. Данные должны быть действительными по падающему фронту MCLK. Если инструкцию необходимо снабдить точкой прерывания, то сигнал BREAKPT должен иметь высокий уровень при следующем нарастающем фронте MCLK. Аналогично, при чтении или записи данных установка BREAKPT во время нарастающего фронта MCLK маркирует данные, как точка наблюдения.

Когда процессор переходит в состояние отладки, устанавливается сигнал DBGACK.

Временная диаграмма внешне-сгенерированных точек прерывания показана на рисунке 5.3.

Рисунок 5. Вход в состояние отладки

Вход в состояние отладки по точке прерывания

Ядро ARM7TDMI определяет, что инструкция содержит точку прерывания еще при поступлении на конвейер, но ядро переходит в состояние отладки только при достижении такой инструкцией ступени исполнения.

Инструкция с точкой прерывания не выполняется. Вместо этого процессор переходит в состояние отладки.

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

Прим.: Процессор переходит в состояние отладки независимо от выполнения условия.

Инструкция с точкой прерывания не вызывает переход ядра ARM7TDMI в состояние отладки в следующих случаях:

Вход в состояние отладки по точке наблюдения

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

Прим.: Точки наблюдения похожи на Авар. данные. Отличие заключается в том, что при возникновении ситуации Авар. данных, несмотря на завершение выполнения инструкции, процессор предотвращает любые последующие изменения состояния процессора ARM7TDMI. Данное действие позволяет вызвать обработчик аварийной исключительной ситуации, устранить причину аварийной ситуации и повторно выполнить инструкцию.

Если точка наблюдения срабатывает после начала обработки исключительной ситуации, то ядро вводит состояние отладки в том же режиме, что и исключительная ситуация.

Вход в состояние отладки по запросу отладки

Процессор ARM7TDMI может быть переведен в состояние отладки при запросе отладки одним из следующих способов:

3.2 Действие процессора в состоянии отладки

Когда ядро ARM7TDMI вводит состояние отладки, сигналы nMREQ и SEQ индицируют внутренние циклы. Это позволяет оставшейся части системы памяти игнорировать ядро и функционировать в нормальном режиме. Поскольку, оставшаяся часть системы продолжает функционировать, то ARM7TDMI игнорирует аварийные ситуации и прерывания.

Система не должна изменять сигнал BIGEND в процессе отладки, поскольку отладчик не подозревает о реконфигурации ядра.

nRESET должен оставаться стабильным в процессе отладки, т.к. сброс ядра в состоянии отладки вызывает потерю слежения за ядром со стороны отладчика.

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

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

4. Домены синхронизации ядра ARM7TDMI

Синхронизация ARM7TDMI описана в параграфе «Синхронизация».

4.1 Переключение синхронизации в состоянии отладки

При переходе процессора ARM7TDMI в состояние отладки происходит автоматическое переключение сигналов синхронизации с MCLK на DCLK, после чего устанавливается сигнал DBGACK во время высокого полупериода MCLK. Переключение между двумя сигналами синхронизации возникает при следующем падающем фронте MCLK. Это демонстрируется на рисунке 5.4.

До завершения отладки ядро использует сигнал DCLK в качестве основного сигнала синхронизации. При выходе из состояния отладки возобновляется синхронизация ядра сигналом MCLK. Это выполняется отладчиком следующим образом:

В этом случае ядро автоматически возвращается к синхронизации сигналом MCLK и запускает выборку инструкций из памяти на частоте MCLK.

См. «Выход из состояния отладки».

Рисунок 5.4. Переключение синхронизации при входе в состояние отладки

4.2 Переключение синхронизации в процессе тестирования

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

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

TAP-контроллер может использоваться для проверки процессора. Если выбраны цепь сканирования 0 и INTEST, то DCLK генерируется, когда цифровой автомат находится в состоянии RUN-TEST/IDLE (запуск тестирования/холостой ход). В состоянии EXTEST DCLK не генерируется.

При выходе из состояния тестирования необходимо ввести в ТАР-контроллер инструкцию RESTART, после чего возобновляется работа MCLK. После проверки INTEST необходимо убедиться, что перед возвращением к нормальной работе ядро находится в восприимчивом состоянии. Наиболее безопасными способами для этого являются следующие:

5. Определение состояния ядра и системы

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

Перед тем как проверить состояние ядра и системы, отладчик путем проверки 4-го бита регистра статуса отладки логики EmbeddedICE должен определить, процессор введен в состояние отладки из состояния Thumb или ARM. Если этот бит равен 1, то ядро введено в состояние отладки из состояния Thumb.

Более детальная информация по определению состояния ядра приведена в параграфе «Определение состояния ядра и системы».

6. Общие сведения о логике EmbeddedICE

Логика EmbeddedICE процессора ARM7TDMI поддерживает встроенные функции отладки ядра ARM7TDMI.

Логика EmbeddedICE программируется последовательно с помощью ТАР-контроллера процессора ARM7TDMI. На рисунке 5.5 иллюстрируется соотношение между ядром, логикой EmbeddedICE и TAP-контроллером с указанием только используемых сигналов.

Рисунок 5.5. ARM7TDM, TAP-контроллер и логика EmbeddedICE

Логика EmbeddedICE содержит:

Регистр управления отладкой и регистр состояния отладки полностью управляют работой EmbeddedICE.

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

Прим.: Можно маскировать любой бит для его исключения из процесса сравнения.

Каждый блок точек наблюдения можно конфигурировать как блок точек наблюдения или как блок точек прерывания.

Точки прерывания и точки наблюдения могут быть зависимыми от данных.

7. Отключение EmbeddedICE

Логика EmbeddedICE отключается путем установки низкого уровня на DBGEN.

Замечание: если на вход DBGEN подать непрерывный низкий уровень, то это приведет к отключению логики EmbeddedICE.

Однако этим лучше не пользоваться для повышения безопасности системы.

Если DBGEN в низком состоянии, то:

8. Отладочный коммуникационный канал

Логика EmbeddedICE процессора ARM7TDMI содержит DCC для передачи информации между целевым отлаживаемым устройством и отладчиком. Он реализован как сопроцессор 14 (CP14).

Данные регистры размещены в фиксированных позициях карты регистров логики EmbeddedICE, как показано на рисунке 5.7. Доступ к регистрам со стороны процессора выполняется с помощью инструкций MCR и MRC к сопроцессору 14.

DCC-регистр управления доступен только для чтения. Он управляет синхронизированным подтверждением связи между процессором и отладчиком. Формат регистра управления показан на рисунке 5.6.

Рисунок 5.6. Формат DCC-регистра управления

Ниже приведено назначение каждого бита регистра:

Если смотреть со стороны отладчика, то доступ к регистрам выполняется через цепь сканирования 2 обычным образом. Со стороны процессора, доступ к данным регистрам выполняется с помощью инструкций передачи регистра сопроцессора.

Доступ к DCC-регистрам необходимо осуществлять с помощью инструкций из таблицы 5.1.

Таблица 5.1. Инструкции доступа к DCC-регистру

Поскольку набор инструкций Thumb не содержит сопроцессорных инструкций, то в этом случае рекомендуется выполнять доступ с помощью инструкции SWI.

8.2 Связь через DCC

DCC позволяет принять и отправить сообщение.

Отправка сообщения в отладчик

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

Процессор считывает регистр управления для проверки состояния бита 1:

Поскольку передача данных выполняется от процессора к DCC-регистру записи данных, то устанавливается бит W в DCC-регистре управления. Когда отладчик опрашивает данный регистр, он наблюдает синхронизированные версии бит R и W. Если отладчик определяет, что бит W установлен, то он может считать DCC-регистр записи данных и выполнить его последовательный вывод. По завершении чтения данного регистра данных происходит сброс бита W в DCC-регистре управления. На данном этапе коммуникационный процесс может начаться заново.

Прием сообщения из отладчика

Передача сообщения из отладчика похожа на отправку сообщения в отладчик. В этом случае, отладчик опрашивает бит R в DCC-регистре управления:

Если DCC-регистр чтения данных свободен, то данные записываются в него с помощью интерфейса JTAG.

Со стороны процессора бит R DCC-регистра управления используется следующим образом.

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

Использование DCC с управлением по прерываниям

Альтернативным и потенциально более эффективным методом опроса регистра управления является использование выходов COMMTX и COMMRX процессора ARM7TDMI. Вы можете использовать данные выходы для прерывания процессора, когда:

Данные выходы, как правило, подключаются к системному контроллеру прерываний, управляя входами nIRQ и nFIQ процессора ARM7TDMI.

Источник