Что такое swd интерфейс
Русские Блоги
Кратко опишите различия между различными интерфейсами отладки (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:
Digitrode
цифровая электроника вычислительная техника встраиваемые системы
Реализация JTAG в устройствах с ядром ARM
JTAG в ARM
До сих пор в нашей серии статей о JTAG мы рассматривали стандарт IEEE 1149.1, включая контроллер тестового порта доступа (TAP) и конечный автомат TAP. Затем мы рассмотрели различные физические интерфейсы, доступные для работы с JTAG, включая распиновки для разъемов, а также интерфейсы JTAG и датчики отладки, доступные на рынке.
В этой статье мы собираемся немного отойти от стандарта 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 предоставляет следующие инструкции:
Также регистры данных JTAG включают:
Здесь следует выделить инструкции DPACC и APACC и связанные с ними регистры данных. DPACC (доступ к порту отладки) и APACC (доступ к порту доступа) – это инструкции/регистры, используемые для передачи команд соответствующим точкам доступа устройства. Устанавливая разные значения в регистрах данных DPACC или APACC, отладчик может выполнять разные операции, обычно взаимодействуя с регистрами самих точек доступа и точек доступа. Обратите внимание на разницу между этими регистрами DPACC и APACC (регистры JTAG) и регистрами, встроенными в точки доступа и точки доступа.
Общая методология здесь заключается в том, что отладчик использует интерфейс JTAG или SWD для выполнения инструкций, проходя через конечный автомат TAP, затем инструкции берут данные и загружают их в DP или AP, и, в зависимости от данных, разные регистры внутри доступ к DP или AP, что обеспечивает желаемую связь с системой. Но что такое регистры DP и AP? Доступные регистры DP включают:
А регистры MEM-AP следующие:
Подключения схематично показаны на следующем рисунке:
Подробную информацию о регистрах 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 лучше всего понять, увидев временную диаграмму, показанную на следующем рисунке.
Операции чтения и записи начинаются одинаково, начиная с того, что хост переводит 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.
Что такое swd интерфейс
Технология JTAG широко применяется для тестирования электронных устройств, чаще всего основанные на микроконтроллерах, CPU, CPLD и/или FPGA. JTAG также позволяет аппаратную отладку, чтение/запись памяти, управление ножками I/O, анализ на производительность работающего кода (здесь приведен перевод статьи [1]).
Технология SWD (расшифровывается как Serial Wire Debug) это более современная версия JTAG, требующая для работы только 2 сигнальных выводов вместо как минимум 4 у стандартного JTAG (иногда добавляется еще один сигнал, что доводит количество сигнальных проводников до 5). SWJ это комбинация SWD и традиционного JTAG. Однако на высшем уровне оба этих интерфейса предоставляют аналогичные функции с разными вариациями, зависящими от управляющего ПО и от аппаратного обеспечения.
С одной стороны эта функциональность должна поддерживаться в целевом устройстве (target device). Порт отладки (Debug Port) часто называют JTAG-DP для JTAG и SW-DP для SWD. Устройство с поддержкой SWJ часто комбинирует в себе оба этих стандарта, при этом SWD-сигналы SWDIO и SWCLK повторно используются как JTAG-сигналы JTMS и JTCK (таким образом, SWJ обеспечивает обратную совместимость с традиционным JTAG). Большинство 32-битых микроконтроллеров и чипов SoC имеют на борту один из таких интерфейсов (или оба).
С другой стороны Вам нужен SWJ-адаптер, который может обмениваться данными с устройством по протоколу JTAG и/или SWD. SWJ могут стоить недорого ( 1000$), в зависимости от качества аппаратуры и ПО (и от бренда производителя). Ниже перечислены несколько описаний SWJ-адаптеров.
[ST-Link v2]
ST-LINK/V2 это адаптер от STMicroelectronics, очень удобный для прошивки микроконтроллеров STM8 и STM32 этой компании, таких как серия STM32 F1. Адаптер поддерживает интерфейсы JTAG, SWD и SWIM (последний применяется для STM8).
Эти SWJ-адаптеры основаны на микроконтроллерах STM32F1xx ARM Cortex M3. Любопытно, что адаптер на основе микроконтроллера STM32F1xx применяется для программирования и отладки таких же микроконтроллеров STM32F1xx.
Использование ST-LINK/V2 на Linux. Для нормального использования сначала добавьте правила для обычного пользователя, чтобы можно было получить доступ к этому устройству (правило udev, основанное на идентификаторах VID и PID адаптера, показываемых lsusb). Это делается только один раз перед тем, как адаптер подключается для непосредственного использования:
Для подключения к микроконтроллерам STM32F1xx ARM Cortex M3 используется OpenOCD [9]:
[Клон ST-LINK/V2]
Это полностью содранный с оригинала ST-LINK/V2. Он поставляется в таком же корпусе, с такими же кабелями, выглядит так же, сохранено даже название печатной платы (MB936). Но сама плата не такая же, список деталей (BOM) не совпадает с оригинальным.
Оригинальный адаптер снабжен дополнительной защитой от статического электричества, защитными резисторами и трансивером, позволяющим работать с уровнями сигнала от 1.65V до 5.5V. В клоне это полностью отсутствует, поскольку сигналы интерфейса напрямую подключены к микроконтроллеру. Таким образом, поддерживаются только уровни сигналов 3.3V на отлаживаемой/программируемой системе, и иногда 5V, потому что выводы микроконтроллера допускают по входу уровни 5V (5V tolerant).
[ST-LINK V2 aluminium]
Существует несколько версий плат этого варианта адаптера, и может также отличаться цоколевка.
2014-06-22 ST-LINK V2. Ниже показана схема и внешний вид этих адаптеров.
В адаптере используется интересный трюк для подключения двух светодиодов (LED) на одной ножке порта (PA9):
• Когда ножка выхода порта установлена в лог. 1, зажигается один светодиод
• Когда эта же ножка переводится в лог. 0, зажигается другой светодиод
• Когда ножка переводится в состояние висящего входа, оба светодиода выключается
• Когда выход работает в режиме ШИМ (PWM), Вы можете смешивать эти 2 цвета светодиодов (красный и синий). Это происходит потому, что глаз не замечает быстрых мерцаний, светодиоды находятся рядом и светят в маленькую дырку по центру.
Тот же самый адаптер, но с другой цоколевкой. Выглядит очень похоже на вышеописанный адаптер, но цоколевка сигналов разъема сильно отличается (кроме питания), и используется только один светодиод. На плате нет никакой маркировки сигналов.
2016-01-18 MX-LINK V2. У этого адаптера логотип «M» вместо логотипа ST, что возможно соответствует маркировке «MX-LINK V2» на плате.
[Baite]
Это аналог ST-Link V2 с поддержкой JTAG, SWD и SWIM (для STM8) [2].
Автор статьи [1] сделал для этого адаптера стикер с цоколевкой сигналов.
 |  |
Автор также перерисовал по плате схему. Все выводы коннектора защищены резисторами 220 ом.
Baite-V2A. Более новая версия промаркирована «V2A» (под кварцем), но схема почти такая же, со следующими изменениями:
• Присутствуют все ножки микроконтроллера (есть даже маска пайки между ними).
• Добавлен порт SWD.
• STM32F103C8 заменен на STM32F101CB, но используется как STM32F103 (так же, как в других дешевых адаптерах).
• Используются пассивные элементы меньшего размера.
• Некачественная разводка платы.
[Black Magic Probe]
Адаптер Black Magic Probe [3] (известный как BMP) очень интересный SWJ-адаптер, потому что в него встроен сервер GDB. Таким образом, не нужно запускать сервер OpenOCD, чтобы управлять адаптером SWJ. Вы можете напрямую подключить GDB к этому адаптеру (через драйвер USB CDC ACM).
В этом адаптере также есть порт UART (через второй канал USB CDC ACM). Это очень полезно для отладки в реальном времени, без точек останова (для обмена сообщениями printf).
Поставляемая аппаратура имеет следующие недостатки:
Из-за того, что firmware этого адаптера открыто (open source), его можно портировать на другую аппаратуру, и народ реально этим пользуется [4]. Проект был портирован [5] на blue pill [6]. Также он был портирован и на клон ST-Link V2 [7], но на нем больше нет дополнительного UART. Автор решил сделать порт на baite [2]. На коннекторе используется меньше выводов питания, но зато получается достаточно функциональных выводов для добавления UART (и SRST).
Сборка firmware (ожидается интегрирование патча):
После получения двоичного кода нужно перепрошить им адаптер Baite. Как Вы можете видеть по схеме, выводы JTAG и SWD микроконтроллера не подключены (на плате нет контактных площадок, куда эти выводы припаяны). Но на обратной стороне платы можно найти контрольные точки, чтобы запрограммировать микроконтроллер через serial bootloader:
| Вывод | Сигнал |
| 1 (квадратный) | RX |
| 2 | TX |
| 3 | BOOT0 |
| 4 | +5V |
| 5 | GND |
Чтобы прошить Black Magic firmware автор использовал stm32flash. Поскольку flash защищена от чтения/записи, сначала нужно очистить эти биты опций.
Поскольку этот адаптер основан на микроконтроллере STM32F103C8 с 64 килобайтами flash, DFU bootloader дает возможность использовать только 56 килобайт памяти flash для основного приложения. Blackmagic firmware превышает этот размер, поэтому его нельзя прошить, если программное обеспечение DFU не игнорирует это ограничение. У микроконтроллера STM32F103C8 часто есть 128 килобайт flash, так что все еще можно прошить blackmagic firmware, используя serial bootloader (по адресу 0x08002000). Проверка во время прошивки (verification) гарантирует, что весь код firmware был успешно записан.
Отключите Baite, и снова подключите его через USB. В нем должно запуститься основное программное обеспечение, и операционная система хоста должна обнаружить два порта USB CDC ACM.
Вы можете перепрошить устройство из основного приложения, используя dfu-util (если Вы сможете перевести dfu-util в состояние игнорирования ограничения по размеру памяти):
Цоколевка нового «BMP Baite»:
| Сигнал | Вывод | Вывод | Сигнал |
| SRTST | 1 | 2 | +3.3V |
| +5V | 3 | 4 | JTCK/SWCLK |
| RX | 5 (ключ) | 6 | JTMS/SWDIO |
| GND | 7 | 8 | JTDO/TRACESWO |
| TX | 9 | 10 | JTDI |
Если Вы подключите SRST к сигналу NRST целевой отлаживаемой системы, то можно будет подавать на неё сброс без нажатия кнопки сброса на плате отлаживаемой системы (если конечно такая кнопка есть). Сигнал сброса генерируется следующей командой:
[Altera USB-Blaster]
USB-Blaster это адаптер от компании Altera. Он часто используется для прошивки FPGA, но по сути это обычный адаптер JTAG.
Внимание: вывод VCC
Сначала добавьте правила для обычного пользователя, чтобы он мог получить доступ к устройству (правило udev на основе идентификаторов VID и PID, показываемых lsusb). Это делается только один раз, перед тем как устройство подключается для непосредственного использования:
Чтобы можно было использовать этот адаптер, нужно перекомпилировать OpenOCD для USB-Blaster, чтобы использовалась библиотека libftdi (наверное потому что это клон).
Теперь Вы можете использовать адаптер, пример с микроконтроллером STM32F1:
Оригинальный адаптер Altera USB-Blaster использует чипы FTDI FT245 и MAX CPLD. Имеется множество его клонов разного качества и разной поддержкой диапазонов напряжения.
[SiLabs USB-Blaster]
Здесь используется микроконтроллер C8051F321 от Silicon Labs и 4-канальный буфер 74LVC125 (для преобразования уровней сигналов в пределах от 1.65V до 3.6V).
[PIC USB-Blaster]
Этот адаптер использует микроконтроллер PIC18F14 компании Microchip, без каких-либо буферов (поддерживаются только сигналы с уровнями 5V).
[ARMJISHU USB-Blaster]
Здесь используется STM32F101 от ST (как STM32F103 с поддержкой USB) и 8-канальный буфер 74HC244 (для преобразования уровней от 2.0V до 6.0V).
На схеме видно, что аппаратура может также управлять сигналами (на 3.3V) в случае, когда Vcc_target не подключен, и Вы можете добавить слот карт uSD или память SPI flash. Не известно, поддерживается ли этот функционал в программном обеспечении.
[SEGGER J-Link]
O-Link-ARM V8 [8], клон SEGGER J-Link.
Поддерживает JTAG, SWD, SWO, RTCK и опорное напряжение для регулировки уровней, что делает этот JTAG-адаптер наиболее полным.
[Цепочка сканирования JTAG]
Микросхемы с поддержкой JTAG имеют точки тестирования, которые называются Test Access Points (TAP). Один микроконтроллер может иметь несколько TAP, соединяемых в цепочку (scan chain). Несколько микросхем с TAP-ми также могут быть соединены (сигналами на печатной плате) в цепочку, это позволяет опрашивать все устройства на плате через одно подключение JTAG. Каждый TAP имеет идентификатор (IDCODE) и он может быть выбран индивидуально.
Иногда полезно перечислить все доступные TAP-ы на цепочке, чтобы узнать, какие есть устройства в системе. Это можно просто осуществить с помощью ПО urJTAG [10]. Пример с USB Blaster:
OpenOCD также сканирует цепочку, если нет предоставленных target (какой используется адаптер, все-таки определить нужно):
0x3ba00477 соответствует Cortex-M3 TAP, и 0x16410041 boundary scan TAP, как указано в документации на STM32F1xx.
Хотя ST-Link v2 с микроконтроллерами ST главным образом используется как адаптер SWD, он также поддерживает обычный JTAG. Оба этих протокола реализованы драйвером High Level Adapter (HLA). Но все выглядит так, как будто scan chain не поддерживается драйвером HLA.