Реализация JTAG в устройствах Arm Core

Эта статья расскажет вам о пересечении JTAG и основных устройств Arm, с особым вниманием к интерфейсу отладки Arm или ADI.

До сих пор в нашей серии статей о JTAG мы рассматривали стандарт IEEE 1149.1, включая контроллер тестового порта доступа (TAP) и конечный автомат TAP. Затем мы рассмотрели различные физические интерфейсы, доступные для работы с JTAG, включая общие выводы для разъемов, а также интерфейсы JTAG и датчики отладки, доступные на рынке.

В этой статье мы собираемся немного отойти от стандарта JTAG и вместо этого посмотрим, как JTAG реализован во вездесущих устройствах ядра ARM.

Что такое рука?

Arm относится к архитектуре процессора, а также к большому объему интеллектуальной собственности, относящейся к интерфейсам микропроцессора и микроконтроллера. Там, где в потребительских ПК обычно используются процессоры, производные от x86, PowerPC или MIPS, встроенная электроника чаще всего реализуется с помощью процессоров Arm-core.

«Ядро» процессоров распространяется среди производителей, таких как ST Microelectronics или NXP, и эти производители затем добавляют дополнительные периферийные функции, такие как интерфейсы I2C и SPI, АЦП и ЦАП, интерфейсы USB и так далее.

Архитектуры Arm имеют версию ARMv, примерами являются ARMv2 (начиная с 1987 года), ARMv6 (процессоры, выпущенные в 2002-2005 годах) и так далее, а ядра процессоров, в которых используются эти архитектуры, маркируются как серия ARMx (ARM1, ARM6, ARM7) и совсем недавно как серия ARM Cortex-A / R / M для высокопроизводительных (Cortex-A) приложений реального времени (Cortex-R) и микроконтроллеров (Cortex-M). Управление версиями архитектуры следует за суффиксом Cortex, став такими версиями, как ARMv6-M, ARMv7-R, ARMv7-A.

Интерфейс отладки Arm подпадает под названием Arm CoreSight Architecture; это включает интерфейс отладки (Arm Debug Interface, ADI), встроенные макроячейки трассировки (ETM), высокоскоростные последовательные порты трассировки (HSSTP) и архитектуру трассировки потока программы CoreSight. ADI формирует основу для операций отладки с процессорами Arm-core, и часть этого стандарта включает интерфейс JTAG, а также альтернативу Serial Wire Debug (SWD). Тема этой статьи - ADI и, в частности, уровни аппаратного интерфейса.

Введение в интерфейс отладки Arm (ADI)

Arm Debug Interface (ADI) - это спецификация как аппаратного, так и логического интерфейса для отладки между хостом и одним или несколькими устройствами. В настоящее время большинство процессоров реализуют ADIv5 (указанный в Arm IHI0031E), в то время как новый ADIv6 (см. Arm IHI0074C) постепенно внедряется. Поскольку он более популярен, мы сосредоточимся здесь на стандарте ADIv5.

ADI определяет порт доступа отладки (DAP), состоящий из порта отладки (DP) и портов доступа (AP). DAP - это основная «единица» интерфейса отладки. У данного устройства будет один порт отладки, который обрабатывает физическое соединение с отладчиком, а также несколько портов доступа, которые обеспечивают доступ к системным ресурсам, таким как регистры отладки, регистры портов трассировки, таблица ROM или системная память. Таким образом, DP включает в себя физическое соединение (JTAG, SWD), а также некоторые встроенные регистры, и каждая AP имеет свои подключения к системе и ряд собственных регистров.

В ADIv5 есть два типа портов отладки и (в широком смысле) три типа портов доступа. DP могут быть JTAG-DP или SWD-DP, названные в честь интерфейса, используемого для подключения к DAP извне устройства. AP могут быть MEM-AP, обеспечивая доступ к ресурсам путем адресации (аналогично отображению памяти, отсюда и название), JTAG-AP, позволяя соединять цепочки сканирования JTAG со всем блоком отладки (DAP), и в зависимости от производителя. AP, которые не указаны Arm. MEM-AP являются наиболее распространенными и полезными, поэтому мы не будем рассматривать здесь другие типы.

В контексте JTAG мы ожидаем, что интерфейс отладки будет предоставлять коды инструкций JTAG, а также функции JTAG, зависящие от поставщика. Фактически, стандарт ADIv5 предоставляет следующие инструкции:

• EXTEST (0b00000000)
• ОБРАЗЕЦ (0b00000001)
• ПРЕДВАРИТЕЛЬНАЯ ЗАГРУЗКА (0b00000010)
• ИНТЕСТ (0b00000100)
• ЗАЖИМ (0b00000101)
• HIGHZ (0b00000110)
• ABORT (0b11111000)
• DPACC (0b11111010)
• APACC (0b11111011)
• IDCODE (0b11111110)
• ОБХОД (0b11111111)

Также регистры данных JTAG включают:

• ABORT (35 бит), регистр для принудительного прерывания порта доступа.
• DPACC (35 бит), регистр доступа для чтения / записи порта отладки
• APACC (35 бит), регистр доступа для чтения / записи порта доступа
• IDCODE (32 бита)
• ОБХОД (1 бит)

Здесь следует выделить инструкции DPACC и APACC и соответствующие регистры данных. DPACC (доступ к порту отладки) и APACC (доступ к порту доступа) - это инструкции / регистры, используемые для передачи команд соответствующим точкам доступа и точкам доступа устройства. Устанавливая разные значения в регистрах данных DPACC или APACC, отладчик может выполнять разные операции, обычно взаимодействуя с регистрами самих точек доступа и точек доступа. Обратите внимание на разницу между этими регистрами DPACC и APACC (регистры JTAG) и регистрами, встроенными в точки доступа и точки доступа.

Общая методология здесь заключается в том, что отладчик использует интерфейс JTAG или SWD для выполнения инструкций, проходя через конечный автомат TAP, затем инструкции берут данные и загружают их в DP или AP, и, в зависимости от данных, разные регистры внутри Доступ к DP или AP осуществляется, обеспечивая желаемый канал связи с системой.

Итак, что такое регистры DP и AP? Доступные регистры DP включают:

• CTRL / STAT, используется для управления и получения информации о состоянии DP.
• DLCR, регистр управления каналом передачи данных, управляет режимом работы канала передачи данных.
• DLPIDR, регистр идентификации протокола передачи данных, информация о версии протокола
• DPIDR, регистр идентификации порта отладки, информация о порте отладки
• EVENTSTAT, регистр состояния события, используемый системой для сигнализации о событии внешнему отладчику.
• RDBUFF, регистр буфера чтения, обеспечивает операцию чтения; зависит от DP (JTAG или SWD)
• SELECT, AP Select register, выбирает порт доступа и банки активных регистров с этой AP; выбирает банк адресов DP
• TARGETID, предоставляет информацию о цели, когда хост подключен к одному устройству.

В то время как регистры MEM-AP:

• Регистр управляющего слова / слова состояния (CSW, 0x00), содержит информацию об управлении и состоянии.
• Регистр адреса передачи (TAR, 0x04), содержит адрес для следующего доступа к системе памяти или системному ресурсу.
• Регистр чтения / записи данных (DRW, 0x0C), устанавливает чтение или запись адреса в TAR - если вы читаете DRW, доступ устанавливается на чтение; если вы пишете в DRW, устанавливается доступ для записи
• Регистры банковских данных (от BD0 до BD3, 0x10, 0x14, 0x18, 0x1C), обеспечивают прямой доступ для чтения или записи к четырем 32-битным блокам памяти, начиная с адреса в TAR.
• Регистр конфигурации (CFG, 0xF4), информация о конфигурации MEM-AP
• Регистр базового адреса Debase (BASE, 0xF8), указатель на систему памяти, либо начало набора регистров отладки, либо начало таблицы ROM.
• Регистр идентификации (IDR, 0xFC), идентифицирует MEM-AP.

Подключения схематично показаны на Рисунке 1 ниже.

Рисунок 1. Схема интерфейса Arm Debug, резюмирующая соединения. Примечание. Для точек доступа и точек доступа показаны не все регистры.

Подробную информацию о регистрах DP / AP и отображении памяти можно найти в спецификации IHI 0031E. Вместо того чтобы вдаваться в подробности, я хотел бы сосредоточиться на другом типе порта отладки, SWD-DP, и на том, как он реализует JTAG, используя только два провода.

Отладка последовательного порта (SWD)

Хотя JTAG-DP является распространенным и знакомым примером интерфейса отладки, наиболее актуальной для нашего обсуждения является альтернатива JTAG, определенная для устройств Arm, Arm Serial Wire Debug (SWD). SWD был разработан как двухпроводной интерфейс для устройств Arm-core с ограниченным количеством выводов. Поскольку микроконтроллеры имеют тенденцию быть довольно плотными в периферийных устройствах, большинство устройств Cortex-M будут реализовывать SWD вместо полного JTAG для экономии места на выводах. Так как же работает этот протокол?

SWD указан в спецификации ADIv5 (глава B4). Выводы TDI и TDO от JTAG заменены одним двунаправленным выводом SWDIO; вывод выбора тестового режима (TMS) полностью удален; и часы (TCK) остаются прежними (помечены как CLK или SWCLK). Таким образом, SWD использует только два контакта по сравнению с четырьмя контактами, используемыми в JTAG. Для выполнения этой работы SWD полагается на повторяющуюся природу операций JTAG:манипулируют конечным автоматом, данные сдвигаются или удаляются, а процесс повторяется. Отличие SWD в том, что там нет конечного автомата. Вместо этого команды выдаются последовательно через SWDIO, а затем тот же вывод используется для чтения или записи данных.

Связь SWD делится на три фазы:запрос пакета, подтверждение и передача данных. Во время запроса пакета платформа хоста выдает запрос к DP, за которым должен следовать ответ с подтверждением. Если пакетный запрос был запросом на чтение или запись данных и было действительное подтверждение, система переходит в фазу передачи данных, где данные синхронизируются (запись) или синхронизируются (чтение) через SWDIO. После передачи данных хост отвечает либо за запуск запроса пакета, либо за управление интерфейсом SWD с циклами ожидания (синхронизация SWDIO LOW). Проверка четности применяется к запросам пакетов и фазам передачи данных.

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

Рисунок 2. Временные диаграммы, показывающие операции чтения и записи для Serial Wire Debug. [Нажмите, чтобы увеличить]

Операции чтения и записи начинаются одинаково, начиная с того, что хост переводит строку SWDIO в стартовый бит, который является сигналом HIGH. Затем следует конфигурация, включая бит доступа AP или DP (APnDP), бит чтения или записи (RnW), адрес (A [2:3]), бит четности (PAR) и стоповый бит ( сигнал LOW), за которым, наконец, следует бит Park, который возникает, когда хост переводит линию в HIGH, прежде чем линия перейдет в режим поворота. Во время оборота ни цели, ни хосту не разрешается управлять линией.

В зависимости от значения RnW выбирается операция чтения или записи. При записи цель предоставляет 3-битный сигнал ACK, затем есть еще один период обработки, за которым следуют 32-битные данные, которые должны быть записаны (WDATA), и бит четности. При чтении цель выдает ACK, а затем продолжает управлять линией с 32-битными данными чтения (RDATA), за которыми следует бит четности. Если произошла ошибка, биты ACK укажут на ошибку, и хост может попытаться перезапустить операцию. Обратите внимание, что WDATA и RDATA передаются в первую очередь младшим значащим битом (LSb), что показано на рисунке 2 путем записи WDATA [0:31] вместо WDATA [31:0].

В документе Arm IHI0031E представлены дополнительные временные диаграммы для пояснения различных случаев связи, но указанные выше являются основными вариантами использования. Стоит отметить, что существует (на момент написания) две версии SWD; SWDv1 поддерживает только одно соединение между хостом и целью (точка-точка), тогда как SWDv2 реализует связь между одним хостом и несколькими целями (многоточечная). Версия 2 почти обратно совместима с версией 1, за исключением нескольких крайних случаев.

Другие варианты JTAG

SWD - не единственный двухпроводной вариант стандарта JTAG IEEE 1149.1. Примечательно, что стандарт IEEE 1149.7 предоставляет интерфейс JTAG с уменьшенным количеством выводов (2-проводный). Другие стандарты 1149.x, такие как IEEE 1149.4 (стандарт для шины тестирования смешанных сигналов) и IEEE 1149.6 (стандарт граничного сканирования для современных цифровых сетей), были разработаны за последние два десятилетия и обеспечивают дополнительную функциональность для более сложных приложений. Сюда входят такие вещи, как аналоговое тестирование с граничным сканированием и улучшенные возможности для дифференциальных линий и линий связи по переменному току.

Самые последние стандарты доступны на веб-сайте IEEE Standards Association.

Заключение

На этом мы завершаем рассмотрение JTAG и SWD. Из этой серии статей мы узнали, откуда берется JTAG, как он работает и как используется для отладки и программирования устройств. Мы рассмотрели физические соединения для JTAG, включая доступные коннекторы и интерфейсы, как коммерческие, так и с открытым исходным кодом. Наконец, мы закончили обзором реализации JTAG для популярных технологий ядра процессора Arm, включая двухпроводной интерфейс SWD.

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