цифровая электроника
вычислительная техника
встраиваемые системы

 
» » Реализация JTAG в устройствах с ядром ARM


Реализация JTAG в устройствах с ядром ARM

Автор: Mike(admin) от 5-01-2021, 05:35

JTAG в ARM


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


Реализация JTAG в устройствах с ядром ARM

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


Что такое 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 извне устройства. Точки доступа могут быть MEM-AP, предоставляя доступ к ресурсам путем адресации (аналогично отображению памяти, отсюда и название), JTAG-AP, что позволяет подключать цепочки сканирования JTAG ко всему отладочному устройству (DAP), и зависит от производителя ТД, не указанные Arm. MEM-AP являются наиболее распространенными и полезными, поэтому мы не будем рассматривать здесь другие типы.


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


  • EXTEST (0b00000000)
  • SAMPLE (0b00000001)
  • PRELOAD (0b00000010)
  • INTEST (0b00000100)
  • CLAMP (0b00000101)
  • HIGHZ (0b00000110)
  • ABORT (0b11111000)
  • DPACC (0b11111010)
  • APACC (0b11111011)
  • IDCODE (0b11111110)
  • BYPASS (0b11111111)

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


  • ABORT (35 бит), регистр для принудительного прерывания порта доступа
  • DPACC (35 бит), регистр доступа для чтения/записи порта отладки
  • APACC (35 бит), регистр доступа для чтения/записи порта доступа
  • IDCODE (32 бита)
  • BYPASS (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

Подключения схематично показаны на следующем рисунке:


Реализация JTAG в устройствах с ядром ARM

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


Serial Wire Debug (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 лучше всего понять, увидев временную диаграмму, показанную на следующем рисунке.


Реализация JTAG в устройствах с ядром ARM

Операции чтения и записи начинаются одинаково, начиная с того, что хост переводит 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), что показано на рисунке путем записи WDATA (0:31) вместо WDATA (31: 0).


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


Заключение


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




© digitrode.ru


Теги: JTAG, ARM




Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Комментарии:

Оставить комментарий