|
В этой статье приведен перевод документации на OpenOCD - популярная система отладки для микроконтроллеров (для OpenOCD release 0.7.0 от 4 мая 2013 года). Поскольку перевод получился объемным, то для удобства он условно был разделен на 3 части - начало, продолжение и окончание. Непонятные термины и сокращения см. в последней части перевода, в разделе Словарик (OpenOCD: руководство пользователя, окончание). Раздел Ссылки также размещен в последней части перевода.
В первой части приведены разделы:
1. OpenOCD Developer Resources, ресурсы для разработчиков OpenOCD.
2. Аппаратура адаптеров для отладки (Debug Adapter Hardware).
3. Что такое Jim-Tcl.
4. Запуск OpenOCD.
5. Настройка проекта для работы с OpenOCD.
6. Указания по составлению файла конфигурации (Config File Guidelines).
7. Конфигурация демона (Daemon Configuration).
8. Конфигурация адаптера отладки (Debug Adapter Configuration).
9. Конфигурация сброса (Reset Configuration).
OpenOCD: руководство пользователя, продолжение
OpenOCD: руководство пользователя, окончание
OpenOCD была создана программистом Dominic Rath как часть диплома. Созданная система выросла в активный проект с открытым исходным кодом, который поддерживается большим сообществом разработчиков программного обеспечения и аппаратуры во всем мире.
[Что такое OpenOCD?]
Название OpenOCD произошло от сокращения Open On-Chip Debugger (открытый отладчик для чипов). OpenOCD предоставляет инструментарий отладки (debugging), внутрисхемного программирования (in-system programming, ISP), внутрисхемного тестирования (boundary-scan testing) для встраиваемых систем (микроконтроллеров, FPGA и т. п.). OpenOCD предоставляет доступ к адаптеру для отладки (debug adapter) - маленькому аппаратному модулю, который помогает получить требуемые сигналы для отладки целевого устройства (обычно с одной стороны адаптер подключается к компьютеру через USB, а с другой стороны имеется интерфейс JTAG [1], через который подключено отлаживаемое устройство). Такой адаптер нужен, так как у хоста отладки (компьютер, на котором запущен OpenOCD) нет поддержки специальных сигналов и коннектора, необходимых для подключения к целевому устройству.
Отладочные адаптеры поддерживают один или несколько транспортных протоколов, каждый из которых использует различные электрические сигналы (и используют разные протоколы поверх этих сигналов). Таким образом, имеется множество типов отладочных адаптеров, и совсем немного стандартизации для них (в дополнение к различным наименованиям адаптеров).
Адаптеры иногда оформлены как отдельные модули, которые обычно называют hardware interface dongle (по-русски это аппаратный отладчик). Некоторые отладочные платы (development boards) также имеют встроенный аппаратный отладчик, так что такая плата может быть напрямую подключена к хосту отладки (debug host) через USB (и, кроме того, иногда может также получать питание от USB).
Например, адаптер JTAG поддерживает систему сигналов JTAG, и использует для обмена данными с JTAG (IEEE 1149.1) совместимыми TAP на Вашей целевой плате (target board). TAP является аббревиатурой от "Test Access Port", специальный модуль в составе микросхемы, который обрабатывает специальные инструкции и данные. TAP-ы поддерживают выстраивание в цепочку (daisy-chained, см. [1]), так что несколько микросхем и даже плат могут быть подключены к одному адаптеру отладки. JTAG поддерживает отладку (debugging) операции пограничного тестирования (boundary scan operations).
Имеются также адаптеры SWD, которые поддерживают систему сигналов Serial Wire Debug (последовательный отладочный интерфейс, SWD) для обмена с новыми ядрами ARM. Также некоторые debug adapter-ы поддерживают оба транспорта - как JTAG, так и SWD. SWD поддерживает только отладку, тогда как JTAG можно использовать как для отладки, так и для boundary scan-а.
Некоторые микросхемы также имеют адаптеры для программирования (Programming Adapter), которые поддерживают специальный транспорт, который используется только для записи (и чтения) кода в память FLASH, без поддержки отладки или boundary scan. На момент написания статьи (май 2013 года) OpenOCD не поддерживает такие адаптеры, не предназначенные для отладки.
Адаптеры отладки: OpenOCD в настоящий момент поддерживает множество типов аппаратных отладчиков (hardware dongle): на основе USB, параллельного порта LPT и другие выделенные модули, внутри которых работает OpenOCD. См. раздел [2. Аппаратура адаптеров для отладки (Debug Adapter Hardware)].
GDB Debug: на этом протоколе можно отлаживать ядра, основанные на ARM7 (ARM7TDMI и ARM720t), ARM9 (ARM920T, ARM922T, ARM926EJ–S, ARM966E–S), XScale (PXA25x, IXP42x) и Cortex-M3 (Stellaris LM3, ST STM32 и Energy Micro EFM32).
Flash Programing: запись FLASH поддерживается для внешних (external) CFI-совместимых модулей NOR flash (с набором команд Intel и AMD/Spansion) и некоторых чипов со встроенной памятью flash (LPC1700, LPC1800, LPC2000, LPC4300, AT91SAM7, AT91SAM3U, STR7x, STR9x, LM3, STM32x и EFM32). Предварительно также поддерживаются различные контроллеры NAND flash (LPC3180, Orion, S3C24xx и другие).
Имеется форум OpenOCD User’s Forum (phpBB), размещенный на сайте SparkFun, который может помочь Вам по многим вопросам. Имейте в виду, что если Вы хотите привлечь внимание разработчиков, то вместо этого форума нужно обратиться в список рассылки OpenOCD Developer Mailing List.
OpenOCD User’s Mailing List site:lists.sourceforge.net предоставляет обмен сообщениями между пользователями. Поддерживается также OpenOCD IRC site:irc.freenode.net.
[1. OpenOCD Developer Resources, ресурсы для разработчиков OpenOCD]
Если Вы заинтересованы в улучшении состояния OpenOCD в плане поддержки отладки и тестирования, то любые пожертвования и деловое участие приветствуются. Мотивированные разработчики могут предоставить новые драйверы для целевых систем, FLASH или интерфейсов, улучшить документацию, а также устранить ошибки или добавить некоторые новые полезные возможности. Ресурсы в этом разделе доступны для разработчиков, которые хотят просмотреть или расширить исходный код OpenOCD source code.
Во время цикла релиза 0.3.x OpenOCD перешла с репозитория Subversion (SVN) на репозиторий GIT, который размещен на SourceForge. URL репозитория: git://git.code.sf.net/p/openocd/code.
Или через HTTP, http://git.code.sf.net/p/openocd/code. Вы можете предпочесть использовать зеркало по протоколу HTTP, http://repo.or.cz/r/openocd.git.
Для клонирования, инициализации и обновления локального репозитория используйте стандартные инструменты GIT, команды git clone, git pull. Имеются также страницы gitweb, которые позволяют просматривать репозиторий через обычный браузер, или загрузить произвольные снимки репозитория (snapshot) даже без необходимости установки программного обеспечения клиента GIT, http://repo.or.cz/w/openocd.git.
В файле README имеются инструкции по сборке проекта из репозитория или из снимка. Весьма приветствуются разработчики, которые хотят предоставить исправления системы OpenOCD (patches, патчи) в главном потоке разработки. Патчи, которые предоставлены к старым версиям, могут потребовать дополнительной рабочей формы для того, чтобы принимающий исправление разработчик мог исправить новые релизы OpenOCD.
1.2. Руководство разработчика в формате документации Doxygen (Doxygen Developer Manual)
Начиная с релиза 0.2.x проект OpenOCD начал предоставлять руководство в формате Doxygen. В этом документе содержится дополнительная техническая информация по поводу внутренней структуры программного обеспечения, процессам разработки и соответствующей документации: http://openocd.sourceforge.net/doc/doxygen/html/index.html.
Этот документ находится в постоянной разработке, но добровольная помощь может заполнить недостающие части. Все исходные файлы, предоставляющие поддержку дерева документации, перечислены в конфигурации Doxyfile, в вершине дерева исходного кода.
1.3. Список рассылки разработчиков (OpenOCD Developer Mailing List)
Этот список рассылки специально предназначен для общения разработчиков: https://lists.sourceforge.net/mailman/listinfo/openocd-devel
Обсуждение и подтверждение патчей происходит через этот список. Файл HACKING содержит базовую информацию о том, как подготовить патчи (исправления).
1.4. База данных багов (OpenOCD Bug Database)
Начиная с релиза 0.4.x команда проекта OpenOCD начала использовать базу данных трекинга ошибок (Trac): https://sourceforge.net/apps/trac/openocd.
[2. Аппаратура адаптеров для отладки (Debug Adapter Hardware)]
Все аппаратные адаптеры (за исключением Zylin ZY1000, который подключается через Ethernet) оформлены как маленький корпус (или печатная плата), подключающийся к компьютеру через USB (иногда через параллельный порт принтера, LPT).
Zylin ZY1000: достоинство этого адаптера в том, что для него не нужно устанавливать никаких драйверов на компьютер PC разработчика, и он имеет также встроенный WEB-интерфейс. Zylin ZY1000 поддерживает RTCK/RCLK или подстраиваемую тактовую частоту (adaptive clocking) и имеет встроенное реле для того, чтобы удаленно управлять питанием отлаживаемых устройств.
2.1. Выбор адаптера
Есть несколько моментов, которые надо учитывать, когда Вы делаете выбор используемого для отладки адаптера.
1. Transport. Поддерживает ли адаптер транспорт (тип обмена) с устройством, который Вам нужен? OpenOCD в основном фокусируется на транспорте JTAG. Ваша версия может также поддерживать другие способы соединения с target device.
2. Voltage, рабочее напряжение. Какое напряжение питания использует Ваша target - 1.8, 2.8, 3.3, или 5V? Поддерживает ли Ваш адаптер его? Если нет, то может понадобиться преобразователь логических уровней (level converter).
3. Pinout, цоколевка кабеля (обычно JTAG). Какая цоколевка разъема подключения на Вашей target board? Ваш адаптер поддерживает её? Вы можете использовать провода перемычек, или коннектор в виде "осьминога" (octopus connector), чтобы адаптировать цоколевку к Вашему адаптеру.
4. Connection (соединение с компьютером). Есть ли на Вашем компьютере (хосте отладки) необходимый для подключения порт USB, LPT или Ethernet?
5. RTCK. Разбираетесь или Вы в использовании чипов ARM и плат с поддержкой RTCK? Эта особенность также известна как "адаптивное тактирование" (adaptive clocking).
2.2. Выделенные системы все-в-одном (Stand alone Systems)
К ним относится ZY1000, см. http://www.ultsol.com/index.php/component/content/article/8/33-zylin-zy1000-jtag-probe. Технически это не донгл, а специальный выделенный для отладки сервер (standalone box).
2.3. USB-адаптеры, основанные на FT2232 компании FTDI (USB FT2232 Based)
На рынке представлено множество адаптеров USB JTAG, и многие из них основаны на микросхеме компании "Future Technology Devices International" (FTDI). Эти микросхемы называются FT2232 (такие как FT2232D [5], FT2232H [6] и другие), и они поддерживают скорость обмена USB full speed (12 мегабит/сек, например в случае FT2232D) и USB high speed (480 мегабит/сек в случае FT2232H). Дополнительные подробности найдете на сайте FTDI. Адаптеры на основе FT2232H могут поддерживать адаптивное тактирование.
Микросхемы FT2232 достаточно гибкие в использовании, чтобы можно было их использовать для других опций транспорта, таких как SWD или вариантов SPI для программирования некоторых чипов. FT2232 имеют два канала обмена, и один может использоваться в качестве адаптера UART (адаптер RS232 с уровнями TTL, он обычно используется для отладочного консольного вывода), в то время как второй канал используется в адаптере отладки (debug adapter).
Также некоторые платы для разработки (development boards) имеют интегрированный чип FT2232 для обслуживания собственного недорогого встроенного адаптера отладки, и преобразователя usb-to-serial (виртуальный COM-порт). Вот примерный список таких плат:
• usbjtag http://elk.informatik.fh-augsburg.de/hhweb/doc/openocd/usbjtag/usbjtag.html
• jtagkey http://www.amontec.com/jtagkey.shtml
• jtagkey2 http://www.amontec.com/jtagkey2.shtml
• oocdlink http://www.oocdlink.com от Joern Kaipf
• signalyzer http://www.signalyzer.com
• Stellaris Eval Boards http://www.ti.com - эти тестовые и отладочные платы (eval boards) имеют поддержку JTAG и SWD на основе FT2232, и могут использоваться для отладки программ чипов Stellaris. Использование отдельных адаптеров JTAG не обязательно. Эти платы могут также использоваться в режиме "pass through" (сквозной режим), чтобы подключить адаптеры JTAG к другим target board, с запретом отладки чипа Stellaris, установленного на плате.
• TI/Luminary ICDI http://www.ti.com - TI/Luminary In-Circuit Debug Interface (ICDI) Boards включены в Stellaris LM3S9B9x Evaluation Kit-ы. Как и на других неотключаемых FT2232 имеющихся на Stellaris eval board, они могут использоваться для отладки других target board.
• olimex-jtag http://www.olimex.com
• Flyswatter/Flyswatter2 http://www.tincantools.com
• turtelizer2, см. Turtelizer 2, или http://www.ethernut.de
• comstick http://www.hitex.com/index.php?id=383
• stm32stick http://www.hitex.com/stm32-stick
• axm0432 jtag, Axiom AXM-0432 http://www.axman.com - имейте в виду, что этот JTAG был недоступен для продажи начиная с апреля 2012 года.
• cortino http://www.hitex.com/index.php?id=cortino
• dlp-usb1232h http://www.dlpdesign.com/usb/usb1232h.shtml
• digilent-hs1 http://www.digilentinc.com/Products/Detail.cfm?Prod=JTAG-HS1
• opendous http://code.google.com/p/opendous/wiki/JTAG адаптер на основе FT2232H (OpenHardware).
• JTAG-lock-pick Tiny 2 http://www.distortec.com/jtag-lock-pick-tiny-2 (на основе FT232H).
2.4. Адаптеры, совместимые с USB-JTAG / Altera USB-Blaster
Эти устройства также работают на чипах FTDI, однако они не совместимы по протоколу с устройствами FT2232. Устройства USB-JTAG обычно состоят из микросхемы FT245, за которой установлена CPLD, понимающая определенный протокол или эмулирующая этот протокол для некоторой другой аппаратуры.
На хосте отладки эти устройства могут быть видны с различными идентификаторами USB VID/PID, в зависимости от конечного продукта. Драйвер может быть сконфигурирован для поиска любой пары VID/PID (см. секцию команд драйвера).
• USB-JTAG Kolja Waschk’s USB Blaster-compatible adapter http://ixo-jtag.sourceforge.net/
• Altera USB-Blaster http://www.altera.com/literature/ug/ug_usb_blstr.pdf
2.5. Адаптеры на базе USB JLINK (USB JLINK based)
Имеется несколько OEM-версий популярного адаптера Segger J-LINK. Это пример адаптера JTAG, основанного на микроконтроллере AT91SAM7S64.
• ATMEL SAMICE (работает только с микросхемами ATMEL!) http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3892
• SEGGER JLINK http://www.segger.com/jlink.html
• IAR J-Link http://www.iar.com/en/products/hardware-debug-probes/iar-j-link/
2.6. Адаптеры на базе USB RLINK (USB RLINK based)
Компания Raisonance выпускает адаптер, который называется RLink (R-Link). Он есть в урезанной форме на STM32 Primer, жестко подключенный к сигналам JTAG. Он также имеется на STM32 Primer2, но разведен для SWD, не как JTAG (JTAG не поддерживается).
• Raisonance RLink http://www.mcu-raisonance.com/~rlink-debugger-programmer__microcontrollers__tool~tool__html
• STM32 Primer http://www.stm32circle.com/resources/stm32primer.php
• STM32 Primer2 http://www.stm32circle.com/resources/stm32primer2.php
2.7. Адаптеры на базе USB ST-LINK (USB ST-LINK based)
Компания ST Microelectronics имеет свой адаптер, который называется ST-LINK. Он работает только с чипами ST Microelectronics, предназначен для STM32 и STM8.
• ST-LINK этот адаптер доступен как отдельно, так и как часть некоторых китов, как например STM32VLDISCOVERY. http://www.st.com/internet/evalboard/product/219866.jsp
• ST-LINK/V2 этот адаптер также доступен отдельно и в составе некоторых китов, например STM32F4DISCOVERY. http://www.st.com/internet/evalboard/product/251168.jsp
Для информации: оригинальный ST-LINK проходит энумерацию на хосте как mass storage usb class, однако его реализация полностью испорчена (не соответствует стандарту USB MSD). В результате на linux это приводит к проблемам. Есть два самых простых способа заставить linux игнорировать баг ST-LINK:
- modprobe -r usb-storage && modprobe usb-storage quirks=483:3744:i
- добавить "options usb-storage quirks=483:3744:i" к файлу /etc/modprobe.conf
2.8. Адаптеры на базе USB TI/Stellaris ICDI
Компания Texas Instruments имеет адаптер, который называется ICDI. Не перепутайте их с адаптерами на базе чипов FTDI, которые первоначально использовались с отладочными платами TI. Это адаптер, приспособленный к Stellaris LaunchPad.
2.9. Другие USB-адаптеры
• USBprog http://shop.embedded-projects.net/ - использует Atmel MEGA32 и UBN9604
• USB - Presto http://tools.asix.net/prg_presto.htm
• Versaloon-Link http://www.versaloon.com
• ARM-JTAG-EW http://www.olimex.com/dev/arm-jtag-ew.html
• Buspirate http://dangerousprototypes.com/bus-pirate-manual/
• opendous http://code.google.com/p/opendous-jtag/ - использует микросхему AT90USB162
• estick http://code.google.com/p/estick-jtag/
• Keil ULINK v1 http://www.keil.com/ulink1/
2.10. Адаптеры, подключаемые к LPT (IBM PC Parallel Printer Port Based)
Хорошо известны адаптеры-кабели "JTAG Parallel Port" Xilnx DLC5 и Macraigor Wiggler. На рынке есть много клонов и их вариантов. Понятно, что LPT уже почти никогда не делают в современных компьютерах, так что лучше такие адаптеры не использовать, и выбрать адаптер на основе подключения через USB.
• Wiggler, имеющий многочисленные клоны. http://www.macraigor.com/wiggler.htm
• DLC5 - от XILINX - у него тоже много клонов. Адаптер больше не выпускается, и для того, чтобы найти информацию по нему, введите в строке поиска "XILINX DLC5" - схемы в формате PDF легко найти и легко изготовить самому.
• Amontec - JTAG Accelerator http://www.amontec.com/jtag_accelerator.shtml
• GW16402 http://www.gateworks.com/products/avila_accessories/gw16042.php
• Wiggler2 http://www.ccac.rwth-aachen.de/~michaels/index.php/hardware/armjtag
• Wiggler_ntrst_inverted - просто другой вариант Wiggler, см. исходный код src/jtag/parport.c
• old amt wiggler, источник неизвестен, так что возможно на рынке этот адаптер не представлен.
• arm-jtag (другой клон Wiggler) http://www.olimex.com/dev/arm-jtag.html
• chameleon http://www.amontec.com/chameleon.shtml
• Triton, источник неизвестен.
• Lattice ispDownload от Lattice Semiconductor http://www.latticesemi.com/lit/docs/devtools/dlcable.pdf
• flashlink от ST Microsystems http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/DM00039500.pdf
2.11. Другие адаптеры
• ep93xx основанная на EP93xx машина Linux, использующая порты GPIO напрямую.
• at91rm9200 наподобие EP93xx - но на основе ATMEL AT91RM9200, также использующая порты GPIO чипа.
[3. Что такое Jim-Tcl]
OpenOCD использует малую версию "Tcl Interpreter" (интерпретатор TCL), известную как Jim-Tcl. Это язык программирования, предоставляющий простой и расширяемый интерпретатор команд.
Все команды, представленные в этом руководстве, являются расширениями Jim-Tcl. Вы можете использовать их как простые команды, без необходимости учить что-то еще в языке Tcl. Альтернативно Вы может писать программы на Tcl. Подробности можно узнать на сайте Jim, http://jim.berlios.de. Сайт имеет активное и отзывчивое комьюнити, так что если есть вопросы, то пользуйтесь списком рассылки (mailing list). Разработчики Jim-Tcl также подписаны на список рассылки OpenOCD.
• Jim vs. Tcl - урезанная версия Tcl language, который можно найти на сайте http://www.tcl.tk. У Jim-Tcl меньше возможностей. Jim-Tcl состоит из нескольких дюжин файлов .C и .H, и реализует базовый набор команд Tcl. Сравните: Tcl 8.6 имеет архив ZIP на 4.2 мегабайта, состоящий из 1540 файлов.
• Missing Features (возможности, которые были удалены из TCL). Наша практика была следующей: добавить/клонировать реальные возможности Tcl, если/когда они необходимы. Мы открыты для улучшений Jim-Tcl, которые не приведут к раздутию кода. Также есть большое количество возможностей Jim-Tcl, которые не были разрешены в OpenOCD.
• Scripts (скрипты). Конфигурационные скрипты OpenOCD являются скриптами Jim-Tcl. Интерпретатор команд OpenOCD выполняет смесь (новых) команд Jim-Tcl и (старых) оригинальных команд интерпретатора.
• Commands (команды). В telnet-строке команд OpenOCD (или через команды монитора GDB, GDB monitor command) можно вводить Tcl циклы for(), устанавливать переменные, и т. п. Некоторые команды, документированные в этом руководстве, реализованы как скрипты Tcl, от файла startup.tcl внутри сервера.
• Историческое примечание. Jim-Tcl был представлен для OpenOCD весной 2008 года. Осенью 2010, перед релизом 0.5 OpenOCD
0.5 переключен на Jim Tcl в качестве субмодуля git, который значительно облегчил апгрейд Jim Tcl, чтобы получить новые возможности и исправления ошибок Jim Tcl.
• Нужен интенсивный экскурс в Tcl? См. раздел [24. Tcl Crash Course].
[4. Запуск OpenOCD]
Правильно установленный OpenOCD в вашей системе предоставит доступ к адаптерам отладки. В среде Linux это обычно включает установку файла в /etc/udev/rules.d и настройку прав (разрешений, permissions) для OpenOCD. Для MS-Windows для каждого периферийного устройства нужно индивидуально сконфигурировать драйвер, и это не всегда простая процедура. Такие проблемы являются уникальными для каждой операционной системы, и в этом руководстве они не рассматриваются.
Когда Вы будете использовать сервер OpenOCD, различные опции скажут Вам, как должна работать сессия отладки. Опция --help покажет следующее:
bash$ openocd --help
--help | -h отобразить эту подсказку
--version | -v отобразить версию OpenOCD
--file | -f использовать указанный файл конфигурации < name >
--search | -s каталог для поиска конфигурационных файлов и скриптов
--debug | -d установить уровень отладки 0..3
--log_output | -l перенаправить вывод лога в указанный файл < name >
--command | -c run запуск < команды >
Если Вы не указали опции -f или -c, то OpenOCD попытается прочитать конфигурационный файл openocd.cfg. Чтобы указать один или большее количество конфигурационных файлов, используйте опции -f, например:
openocd -f config1.cfg -f config2.cfg -f config3.cfg
Конфигурационные файлы и скрипты ищутся в следующих местах:
1. Текущая директория.
2. Любой каталог поиска, указанный в командной строке через опцию -s.
3. Любой каталог поиска, указанный через команду add_script_search_dir.
4. $HOME/.openocd (не на платформе Windows).
5. Библиотека скриптов (site wide script library) $pkgdatadir/site.
6. Библиотека скриптов, предоставленная OpenOCD $pkgdatadir/scripts.
Будет использоваться первый найденный файл с подходящим именем. Внимание: не пытайтесь использовать имена скриптов или пути, которые содержат символ '#'. С этого символа начинаются комментарии Tcl.
4.1. Простая установка, без дополнительных настроек (Simple setup)
В самом лучшем случае Вы можете использовать два скрипта из одной из библиотек скриптов, подцепить Ваш адаптер JTAG, и запустить сервер ... и после этого настройка JTAG просто заработает "из коробки". Всегда пробуйте начать работу путем повторного использования этих скриптов, но будьте готовы к тому, что потребуется дополнительная настройка, даже если все заработает. См. раздел [5. OpenOCD Project Setup].
Если Вы нашли скрипт для Вашего адаптера JTAG и для Вашей платы или target-а, то Вы можете подцепить Ваш JTAG-адаптер, тогда запустите сервер командой наподобие:
openocd -f interface/ADAPTER.cfg -f board/MYBOARD.cfg
Может также потребоваться сконфигурировать имеющиеся сигналы сброса, используя -c ’reset_config trst_and_srst’ или что-то типа этого. Если все хорошо, то Вы увидите в консоли сообщение наподобие:
Open On-Chip Debugger 0.4.0 (2010-01-14-15:06)
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : JTAG tap: lm3s.cpu tap/device found: 0x3ba00477
(mfg: 0x23b, part: 0xba00, ver: 0x3)
Если видно сообщение "tap/device found" и нет предупреждений, то значит, что обмен через JTAG работает. Это общий принцип, но вероятно что для Вашего проекта понадобится дополнительная специфичная настройка.
4.2. Что OpenOCD делает при старте
OpenOCD начинает с обработки команд конфигурации, представленных в командной строке или, если нет опций -c command или -f file.cfg, в файле openocd.cfg. См. раздел 7.1. Configuration Stage (стадия конфигурации). В конце стадии конфигурации OpenOCD проверяет цепь сканирования JTAG с использованием соответствующих команд; Ваша конфигурация должна гарантировать, что все происходит успешно. Затем обычно OpenOCD начинает работу как демон (сервис). Альтернативно могут использоваться команды для раннего прерывания стадии конфигурации, выполнения работы (такой как обновление некоторой памяти flash), и затем завершения без запуска сервиса (daemon не работает).
Как только OpenOCD запустился как daemon, он ждет соединений от клиентов (Telnet, GDB, или другие порты) и обрабатывает команды, выданные через эти каналы.
Если Вы столкнулись с проблемами, то можете разрешить вывод внутренних отладочных сообщений опцией -d.
Также можно чередовать команды Jim-Tcl с конфигурационными скриптами, используя ключ -c командной строки.
Чтобы разрешить внутренний отладочный вывод OpenOCD (debug output, этот вывод позволяет сообщать о проблемах или о работе самого OpenOCD), используйте в командной строке ключ -d. Это установит debug_level в значение "3", что приведет к выводу большинства информации, включая отладочные сообщения. Значение по умолчанию "2" при этом выводятся только информационные сообщения, предупреждения и ошибки. Вы также можете поменять эту установку через сессию telnet или gdb, используя debug_level < n > (см. раздел 16.1. Daemon Commands).
Вы можете перенаправить вывод демона из консоли в файл ключом -l < имя_лог_файла >. Внимание! OpenOCD запустит серверы GDB и telnet, даже если не установлено соединение с target. Обычно возможна ситуация, что контроллер JTAG не будет работать, пока target не будет корректно настроена, к примеру через команды GDB monitor-а или через скрипт инициализации GDB (GDB init script).
[5. Настройка проекта для работы с OpenOCD]
Для использования OpenOCD совместно с Вашими разрабатываемыми проектами, нужно сделать нечто большее, чем просто подключить адаптер JTAG (донгл) к отладочной плате и запустить сервер OpenOCD. Нужно также сконфигурировать сервер OpenOCD, чтобы он знал о том, какие это адаптер и плата. Вы можете также захотеть подключить OpenOCD к GDB, например с использованием Eclipse или другого GUI (IAR, Keil и т. п.).
5.1. Подключение адаптера JTAG
Сегодня наиболее общий случай донгла - кабель JTAG с одной стороны (например плоский кабель с 10-pin или 20-pin коннектором IDC) и кабель USB с другой. Вместо USB иногда может быть Ethernet; старые донглы могут использовать параллельный порт принтера PC LPT, или даже последовательный порт (RS-232).
1. Начните с отключения питания от target board, и подключения к ней Вашего адаптера JTAG. Самым лучшим, параноидальным решением будет полностью отключить шнур питания от платы, и шнур USB от компьютера. Важно, чтобы был правильно соединен заземляющий сигнал, за исключением случая, когда используется JTAG-адаптер с гальванической изоляцией target board и хоста отладки.
2. Убедитесь, что используете подходящий вид коннектора JTAG. Если на Вашем адаптере коннектор 20-pin ARM, то может понадобиться особый переходник (типа осьминога, octopus) чтобы подцепиться к платам, на которых стоять 14-pin или 10-pin коннекторы, или если 20-pin коннектор не с цоколевкой ARM. Также удостоверьтесь, что уровни напряжения также совместимы. Не все адаптеры JTAG имеют узлы согласования уровня (level shifters), которые нужны для работы с платами на уровнях 1.2 вольта.
3. Убедитесь, что кабель правильно ориентирован, или Вы можете повредить Вашу плату и/или адаптер JTAG. В большинстве случаев имеется только 2 варианта подключения кабеля. Подключите кабель JTAG от Вашего адаптера к плате, при этом убедитесь, что он правильно подключен. Обычно коннектор снабжен направляющим ключом, предотвращающим неправильное физическое подключение. Чаще всего на плате установлен коннектор папа, а на кабеле коннектор мама, и коннекторы снабжены направляющими ключами. Если направляющих нет, то нужно ориентироваться на положение вывода 1 на коннекторе платы и на кабеле. Плоские ленточные кабели часто имеют красную цветовую маркировку на краевом проводе, помечающую вывод 1. Иногда адаптеры имеют кабели в виде "осьминога" с цветовой кодировкой отдельных проводов вместо коннектора в виде блока. Такие коннекторы хороши для преобразования одной цоколевки JTAG в другую, но они неудобны для подключений. Для подключения с таким коннектором используйте диаграммы цоколевки, чтобы не ошибиться в подключении сигналов адаптера JTAG к соответствующим выводам коннектора платы.
4. Соедините другой конец адаптера (когда уже подключен кабель JTAG). Это кабель USB, LPT или RS-232 (COM-порт), подключаемый к хосту, на котором будет запущен OpenOCD. Для варианта подключения Ethernet обратитесь к документации и Вашему администратору локальной сети.
Для USB JTAG адаптеров проверка подключения состоит в том, что видит или нет операционная система адаптер JTAG? Если на хосте установлена операционная система MS-Windows, то Вам нужно установить специальный драйвер для адаптера, чтобы OpenOCD могла работать.
5. Если нужно, подключите питание адаптера. Этот шаг предназначен обычно для не-USB адаптеров, но иногда (что бывает очень редко) USB-адаптеры требуют внешнего дополнительного питания.
6. Подайте питание на target board. Теперь все готово к настройке сервера OpenOCD, после чего можно использовать JTAG для работы с отлаживаемой платой.
С сервером OpenOCD можно общаться через telnet (на большинстве систем для этого достаточно команды telnet localhost 4444) или через GDB. См. раздел [21. GDB and OpenOCD].
5.2. Каталог проекта
Есть несколько способов, как Вы могли бы сконфигурировать и запустить OpenOCD. Самый простой - организовать его запуск из одиночной директории, где находится вся Ваша работа с платой (рабочий каталог проекта). Когда Вы запустите OpenOCD из этого каталога, то OpenOCD именно здесь будет искать сначала файлы конфигурации, скрипты, файлы к которым производится доступ через семихостинг, и код, который выгружается в target board. Каталог проекта - самое подходящее место для записи файлов, таки как лог и данные, которые загружаются из платы.
5.3. Основы конфигурирования OpenOCD
Есть два базовых метода конфигурирования OpenOCD, различные способы их комбинировать. Вот эти два разные метода запуска сервера:
• Несколько опций -f file или -c command в командной строке.
• Нет ни одной опции в командной строке, но в текущем каталоге есть файл openocd.cfg (user config file, файл конфигурации пользователя).
Далее приведен пример файла openocd.cfg для настройки адаптера Signalyzer JTAG, основанного на FT2232 для работы с платой на микроконтроллере Atmel AT91SAM7X256:
source [find interface/signalyzer.cfg]
# GDB может только прошить мою память flash!
gdb_memory_map enable
gdb_flash_program enable
source [find target/sam7x256.cfg]
Вот эквивалент командной строки, выполняющей те же действия:
openocd -f interface/signalyzer.cfg
-c "gdb_memory_map enable"
-c "gdb_flash_program enable"
-f target/sam7x256.cfg
Вы можете обернуть такие длинные командные строки шелл-скриптами для поддержки различных задач разработки. Одна задача может быть перепрошивка платы определенной версией firmware. Другая может настраивать какую-нибудь отладку в окружении выполнения в реальном времени.
Важно: как это было описано (октябрь 2009), метод командной строки имеет проблемы с обращением к переменным. Например, после -c "set VAR value" или после выполнения того же самого действия в скрипте, переменная VAR не будет иметь присвоенного значения, которое может быть протестировано в последующем скрипте.
Здесь мы сфокусируемся на простом решении: один файл конфигурации пользователя, включающий базовую конфигурацию, плюс любые процедуры TCL для упрощения Вашей работы.
5.4. Файлы конфигурации пользователя (User Config Files)
Файл конфигурации пользователя соединяет вместе все части проекта в одном месте. Что-то из следующего лучше всего подойдет к Вашей ситуации:
• Идеальный вариант - когда программное обеспечение поставляется вместе с готовыми конфигурационными файлами. Например, дистрибутив OpenOCD содержит в себе папку scripts (в системе Linux полный путь может быть /usr/share/openocd/scripts). Поставщики отладочных плат и инструментария могут также предоставить файлы скриптов, которые могут находиться в другом месте, в другой папке; опция командной строки -s позволяет указать, где искать эти файлы (см. раздел [4. Запуск OpenOCD]). Ранее приведенный пример с AT91SAM7X256 использует такой метод.
3 главных типа конфигурационных файлов, не относящихся к пользователю, расположены каждый в своей поддиректории папки scripts:
1. interface – в этой папке находятся файлы конфигурации по одному для каждого отдельного адаптера отладки.
2. board – здесь файлы конфигурации для каждой отладочной платы.
3. target – здесь файлы для микроконтроллеров (integrate CPU) и других микросхем, имеющих JTAG TAP.
Лучший случай: просто подключите 2 файла, и этого достаточно. Первый файл - файл конфигурации интерфейса. Второй относится к макетной плате, и настраивает JTAG TAP их GDB target (путем ссылки к некоторому файлу target.cfg), декларирует всю память flash. Больше ничего конфигурировать не нужно, и Вы можете заниматься работой по отладке. Пример подключения двух файлов:
source [find interface/olimex-jtag-tiny.cfg]
source [find board/csb337.cfg]
Макетные платы, на которых нет ничего, кроме одного микроконтроллера, часто нуждаются только к конфигурационном файле для описания цели (target config file), как в этом примере с AT91SAM7X256 example. Это потому, что нет внешней памяти (flash, DDR RAM), и все особенности платы нужно учитывать только в коде приложения firmware.
• Возможно, что Вы пока не знаете, какой JTAG используется на Вашей плате. Чтобы узнать, какой файл interface.cfg использовать, Вам может понадобиться помощь от OpenOCD - чтобы определить, какой JTAG используется. Как только Вы найдете JTAG TAP, то можете просто найти соответствующие конфигурационные файлы target и board, либо написать их самостоятельно на основе указаний далее, см. раздел 10.7. Автоматическое распознавание (Autoprobing).
• Вы можете часто повторно использовать стандартные конфигурационные файлы, но иногда нужно написать еще и свои, например файл board.cfg. Для этого Вы будете использовать команды, описанные в данном руководстве, и работать по схеме, которая приведена в следующем разделе.
Например, уже есть готовые конфигурационные файл для Вашего адаптера JTAG и чипа target, но нужно создать новый файл конфигурации специально для Вашей платы, чтобы получить доступ к внешним микросхемам памяти flash. Или Вы можете нуждаться в конфигурационном файле для другого target chip (новой микросхемы микроконтроллера), построенном на основе ядра Cortex M3.
Внимание: когда Вы пишете новый конфигурационные файлы, пожалуйста предоставьте их на одобрение для включение в следующий релиз OpenOCD. Например, board/newboard.cfg поможет другим пользователям этой платы, и target/newcpu.cfg поможет поддержать пользователей любых плат, использующих этот чип.
• Может быть, Вам нужно написать некий код на C. Это способ может быть проще для поддержки новых адаптеров отладки на основе ft2232; если представить что-то еще, то это может быть код для контроллера памяти NAND или NOR flash, или часть большой работы по поддержке новой архитектуры чипа.
Когда это возможно, используйте уже готовые конфигурационные файлы. Сначала просмотрите папку scripts/boards, затем scripts/targets. Вы можете найти конфигурационный файл платы, который послужит хорошим примером, которого можно придерживаться. Когда Вы пишете конфигурационные файлы, разделяйте его части, которые можно повторно использовать (подумайте о каждом пользователе, которому понадобится этот интерфейс, чип или плата) от частей, которые относятся только к Вашему аппаратному окружению и методам отладки.
• Например, обработчик события gdb-attach, который привлекает команду reset init, будет пересекаться с ранним отладочным кодом загрузки, который выполняет те же действия, что и reset-init обработчика прерывания.
• Аналогично команда arm9 vector_catch (или её сестры xscale vector_catch и cortex_m vector_catch) могут экономить время в сессии отладки, но не заставляйте всех также их использовать. Держите такие методы отладки отдельно, в Вашем собственном конфигурационном файле, вместе с настройкой сообщений и трассировки, см. раздел 17.6. Трассировка и отладочные сообщения программ (Software Debug Messages and Tracing).
• Вам может понадобиться поменять некоторое поведение, заданное по умолчанию. Например, нужно переместить, урезать рабочую область, или делать её резервную копию, если Ваше приложение нуждается в большом количестве SRAM.
• Конфигурация порта TCP/IP - другой пример, относящийся к рабочему окружению, и такая конфигурация должна присутствовать только в конфигурационном файле пользователя (user config file). См. раздел 7.3. Порты TCP/IP.
5.5. Утилиты, относящиеся к специфике проекта (Project-Specific Utilities)
Некоторые подпрограммы утилит, зависящих от проекта, могут ускорить Вашу работу. Напишите их, и сохраните в Вашем конфигурационном пользовательском файла проекта.
Например, если Вы делаете бутлоадер (boot loader), работающий в плате, хорошо иметь возможность отладки "после того, как он будет загружен в RAM” - отдельные части, особенного кода, который настраивает контроллер DDR RAM и тактов. Скрипт наподобие следующего, или похожий скрипт с отключением GDB, может помочь:
proc ramboot { } {
# Сброс, запуск скриптов target "reset-init"
# для инициализации тактов и контроллера DDR RAM.
# CPU остается в остановленном состоянии.
reset init
# Загрузка версии CONFIG_SKIP_LOWLEVEL_INIT в DDR RAM.
load_image u-boot.bin 0x20000000
# Запуск кода.
resume 0x20000000
}
Когда этот код заработает, Вы можете произвести загрузку из памяти NOR flash; здесь может помочь уже другая утилита. Альтернативно некоторые разработчики пишут в память flash, используя GDB. Вы можете использовать похожий скрипт, если работаете с firmware, основанном на flash микроконтроллера, вместо бутлоадера.
proc newboot { } {
# Сброс, после чего CPU остается остановленным. Процедура события
# "reset-init" дает ускоренный доступ к CPU и для NOR flash;
# "reset halt" может быть более медленным.
reset init
# Запишите стандартную версию U-Boot в первые два сектора
# NOR flash ... стандартная версия должна делать тот же
# lowlevel init, как и "reset-init".
flash protect 0 0 1 off
flash erase_sector 0 0 1
flash write_bank 0 u-boot.bin 0x0
flash protect 0 0 1 on
# Полная перезагрузка заново, используя новый бутлоадер.
reset run
}
Вам могут понадобиться более сложные процедуры утилит, когда загружаетесь из NAND. Часто используют дополнительную фазу бутлоадера, запущенную из встроенной в чип памяти SRAM, для выполнения настройки DDR RAM, чтобы можно было загрузить основной код бутлоадера (который в SRAM не помещается).
Другие скрипты-помощники могут использоваться для записи образов систем в производстве, тогда могут использоваться бутлоадеры с более чем тремя стадиями загрузки.
5.6. Изменения целевого программного обеспечения (Target Software Changes)
Иногда Вы можете захотеть сделать незначительные изменения в отлаживаемом программном обеспечении (firmware), чтобы помочь улучшить отладку через JTAG. Например, код C или ассемблера может использовать директивы #ifdef JTAG_DEBUG (или похожие) в коде, чтобы избежать некоторых проблем:
• Таймеры Watchdog (сторожевые таймеры). Эти таймеры обычно используются для того, чтобы автоматически сбросить систему, если какая-то задача в приложении не будет осуществлять периодические обнуления таймера Watchdog (в этом случае предполагается, что задача не может запуститься и система зависла). Когда отладчик JTAG останавливает работу системы, код сброса Watchdog не может запуститься и сбросить таймер... Это потенциально приведет к неожиданному сбросу посередине сессии отладки.
Иногда хорошей идеей будет запретить во время отладки такие сторожевые таймеры, поскольку их использование не требуется для отладки других частей firmware. Выбрать такое решение или нет - зависит от Вас.
Место этого найдите зависящие от микроконтроллера методы остановки таймера WatchdogЮ когда система перешла в состояние приостановки при отладке (debug halt state). Может быть проще всего сделать это - в скриптах запуска отладчика перевести таймер на режим без счета. Другая причина, использовать управляющие скрипты, когда к примеру остановка кода может привести к физическому повреждению аппаратуры (шаговый двигатель может перегореть, когда firmware перейдет в состояние debug halt state). Так что можно использовать некий код firmware с режимом, код остановлен, в начале отладки, и код, который снова разрешает работу аппаратуры, в конце отладки, и остановка программы не приведет к повреждениям1.
Примечание 1: имейте в виду, что многие системы поддерживают "режим монитора", которые могут обеспечить более безопасный способ для диагностики проблем. В таком случае будет приостановлена только часть (отдельная задача) системы, остальные функции будут продолжать работу. В январе 2010 года, когда писалось это примечание, отладка на основе OpenOCD не поддерживала режим монитора (monitor mode debug), только режим отладки с остановом ("halt mode" debug).
• ARM Semihosting. Когда к проекту подключены специальные библиотеки реального времени, предоставленные многими системами разработки 2, Ваш код firmware может использовать возможности ввода/вывода хоста (I/O debug host) - экран компьютера, файл, клавиатуру (это и называется семихостингом). Такие библиотеки предоставляют маленький набор системных вызовов, которые обрабатываются OpenOCD. Это может позволить отладчику предоставить системную консоль и файловую систему, что может помочь в отладке на ранних стадиях разработки, или получить расширенное рабочее окружение для сложных задач типа установки firmware системы в память NAND flash или SPI flash.
Примечание 2: см. раздел [8. Semihosting] в руководстве ARM DUI 0203I, "RealView Compilation Tools Developer Guide". Набор инструментария CodeSourcery EABI также включает в себя библиотеку семихостинга.
• ARM Wait-For-Interrupt. Многие чипы ARM синхронизируют такты JTAG, используя такты ядра. Режимы пониженного энергопотребления, которые останавливают или снижают частоту ядра, могут привести к тому, что JTAG станет недоступным. Циклы ожидания в окружении выполнения задая часто входят в режимы пониженного потребления с помощью инструкции WFI (или другого эквивалента на ARMv7).
Вы можете захотеть запретить эту инструкцию в исходном коде проекта, или другим способом предотвратить пропадание тактирования JTAG - для того, чтобы доступ к JTAG работал всегда3. Иначе, к примеру, команда halt системы OpenOCD может не сработать на приостановленном микроконтроллере.
Примечание 3: в качестве более подходящей альтернативы некоторые процессоры имеют специальные отладочные регистры, которые могут использоваться для изменения возможностей чипа - наподобие того, как будет при отладке изменяться тактовая частота, когда микроконтроллер вошел в режим пониженного энергопотребления. В качестве примера: ядро STM32 имеет регистр DBGMCU_CR. Если правильно его настроить, то JTAG будет работать и в режимах пониженного энергопотребления (ценой того, что при отладке не будет так же снижаться потребление мощности, как в реальной ситуации, без отладки).
• Задержка после сброса. Не все чипы имеют хорошую поддержку доступа для отладчика после сброса; многие чипы LPC2xxx с такой проблемой. Также некоторые приложения, которые реконфигурируют ножки интерфейса JTAG, могут блокировать работу отладчика.
Чтобы работать с такими платами, разрешите короткий цикл задержки, который будет запущен сразу после сброса, перед тем как будут происходить "реальные" стартовые действия в коде firmware. Например, задержка в 1 секунду предоставит достаточно времени для подключения отладчика JTAG, так что выполнение кода на ранних стадиях может быть отлажено или firmware может быть заменено на другое.
• Debug Communications Channel (канал обмена отладки, DCC). Некоторые процессоры имеют механизмы для отправки сообщений поверх JTAG. Многие ядра поддерживают такую возможность, а также некоторые ядра других производителей. OpenOCD может использовать DCC внутри себя, ускоряя некоторые операции наподобие записи в память.
Ваше приложение firmware может захотеть переправить отладочные сообщения через JTAG, для этого к коду firmware должна быть подключена маленькая библиотека, предоставляемая OpenOCD. Можно использовать утилиты из этой библиотеки для того, чтобы отправить разные отладочные сообщения на хост. См. раздел 17.6. Программные отладочные сообщения и трассировка (Software Debug Messages and Tracing). Примечание переводчика: с той же целью часто используют встроенный в микроконтроллер UART (или например DBGU, имеющийся в микроконтроллерах ARM компании ATmel).
5.7. Настройка аппаратуры отлаживаемого устройства (Target Hardware Setup)
Производители микроконтроллеров и микросхем часто предоставляют отладочные платы, которые могут иметь богатые возможности по конфигурированию, так что плата может предоставить поддержку всех нужных опций продукта (например, различной аппаратуры микроконтроллера), которые могут понадобиться. Убедитесь, что перемычки и переключатели соответствуют той конфигурации системы, которая Вам нужна для работы. Вот общие проблемы, с которыми можно столкнуться:
• JTAG setup. Платы могут поддерживать более одной конфигурации JTAG. Примеры включают перемычки, управляющие типом нагрузочных резисторов (pullup или pulldown) на сигналах nTRST и/или nSRST, и выбор коннекторов (например, на базовой плате имеется 2 коннектора, или один коннектор находится на дочерней плате). У некоторых плат компании Texas Instruments может понадобиться замкнуть сигналы EMU0 и EMU1 (которыми OpenOCD в настоящее время управлять не будет).
• Boot Modes (режимы загрузки). Сложные чипы часто поддерживают несколько вариантов загрузки, управляемых внешними перемычками. Убедитесь, что эти перемычки установлены правильно. Например многие платы i.MX компании NXP нужно переключить в режим "ATX mode" для начала загрузки из встроенной в чип ROM, когда используется бутлоадер второй стадии, сохраненный во внешнем чипе NAND flash. Такая явная конфигурация весьма распространена, и не ограничивается загрузкой из NAND. Вам может потребоваться поставить перемычки для запуска загрузки кода с карты MMC/SD, внешней памяти SPI, линков Ethernet, UART, USB, из памяти NOR flash, OneNAND flash, иногда из файла хоста. Могут быть и другие источники загрузки.
• Адресация памяти. Платы, которые поддерживают разные режимы загрузки, могут также иметь перемычки для конфигурирования адресации памяти. На некоторых платах, например, есть перемычки для внешнего сигнала выборки chipselect 0 (используется для загрузки) - чтобы адресовать либо большую SRAM (которая должна быть предварительно загружена через JTAG), NOR flash или NAND flash. Когда перемычки стоят для адресации NAND flash, плата может также загружаться из встроенной в чип памяти ROM.
Ваш файл board.cfg может нуждаться в том, чтобы указать конфигурацию таких перемычек, чтобы знать, использовать банк ли NOR flash командой flash bank вместо NAND flash командой nand device; и аналогично пробовать выполнить обработчик reset-init.
Проблема похожего типа связана с шириной шины. Перемычки могут понадобиться для того, чтобы отделить 8-битный доступ к шине от 16-битного при старте загрузки из памяти flash.
• Peripheral Access (доступ к периферийным устройствам). Отладочные платы обычно предоставляют доступ к каждому периферийному устройству чипа, иногда в разных режимах (такие как предоставление нескольких аудиокодеков чипа). Это работает вместе с программным конфигурированием переключения выводов чипа (pin multiplexing), где к примеру указанный вывод должен быть подключен либо к контроллеру MMC/SD, либо к контроллеру GPIO. Это также часто связано с положением конфигурационных перемычек. Одна перемычка может использоваться для подвода сигнала к слоту карты MMC/SD или к коннектору шины расширения; другая перемычка может управлять подключением используемого аудио- или видеокодека.
Плюс конечно же Вы должны иметь обработчики события (reset-init event handlers), которые настраивают аппаратуру для соответствия положению перемычек. Это включает, в частности, любой генератор или PLL, используемый для тактирования CPU, и любые контроллеры памяти, которые нужны для доступа к внешней памяти и периферии. Без таких обработчиков Вы не сможете получить доступ к этим ресурсам без работы target firmware, которое могло бы настроить все должным образом ... так что попытка отладить firmware будет происходить весьма неуклюже. Даже если имеется ROM bootloader, который обрабатывает решение некоторых проблем, он редко когда предоставит полный доступ ко всем встроенным возможностям какой-то отдельной отладочной платы.
[6. Указания по составлению файла конфигурации (Config File Guidelines)]
Этот раздел предназначен для пользователя, который намерен написать конфигурационный файл, включая разработчиков и интеграторов OpenOCD, и любого пользователя, кто хочет добиться качественной работы новой платы. Здесь предоставлены указания по созданию таких файлов.
Вам нужно найти следующие подпапки, находящиеся в директории $(INSTALLDIR)/scripts. Используйте эти файлы как есть в оригинальном виде, или как модели для написания новых.
• interface - здесь сосредоточены файлы конфигурации для адаптеров отладки. Вы можете найти здесь файлы для конфигурирования различных адаптеров JTAG.
$ ls interface -R
interface/:
altera-usb-blaster.cfg hilscher_nxhx50_re.cfg openocd-usb-hs.cfg
arm-jtag-ew.cfg hitex_str9-comstick.cfg openrd.cfg
at91rm9200.cfg icebear.cfg osbdm.cfg
axm0432.cfg jlink.cfg parport.cfg
busblaster.cfg jtagkey2.cfg parport_dlc5.cfg
buspirate.cfg jtagkey2p.cfg redbee-econotag.cfg
calao-usb-a9260-c01.cfg jtagkey.cfg redbee-usb.cfg
calao-usb-a9260-c02.cfg jtagkey-tiny.cfg rlink.cfg
calao-usb-a9260.cfg jtag-lock-pick_tiny_2.cfg sheevaplug.cfg
chameleon.cfg kt-link.cfg signalyzer.cfg
cortino.cfg lisa-l.cfg signalyzer-h2.cfg
digilent-hs1.cfg luminary.cfg signalyzer-h4.cfg
dlp-usb1232h.cfg luminary-icdi.cfg signalyzer-lite.cfg
dummy.cfg luminary-lm3s811.cfg stlink-v1.cfg
estick.cfg minimodule.cfg stlink-v2.cfg
flashlink.cfg neodb.cfg stm32-stick.cfg
flossjtag.cfg ngxtech.cfg sysfsgpio-raspberrypi.cfg
flossjtag-noeeprom.cfg olimex-arm-usb-ocd.cfg ti-icdi.cfg
flyswatter2.cfg olimex-arm-usb-ocd-h.cfg turtelizer2.cfg
flyswatter.cfg olimex-arm-usb-tiny-h.cfg ulink.cfg
ftdi olimex-jtag-tiny.cfg usb-jtag.cfg
hilscher_nxhx10_etm.cfg oocdlink.cfg usbprog.cfg
hilscher_nxhx500_etm.cfg opendous.cfg vpaclink.cfg
hilscher_nxhx500_re.cfg opendous_ftdi.cfg vsllink.cfg
hilscher_nxhx50_etm.cfg openocd-usb.cfg xds100v2.cfg
interface/ftdi:
axm0432.cfg icebear.cfg oocdlink.cfg
calao-usb-a9260-c01.cfg jtagkey2.cfg opendous_ftdi.cfg
calao-usb-a9260-c02.cfg jtagkey2p.cfg openocd-usb.cfg
cortino.cfg jtagkey.cfg openocd-usb-hs.cfg
dlp-usb1232h.cfg jtag-lock-pick_tiny_2.cfg openrd.cfg
dp_busblaster.cfg kt-link.cfg redbee-econotag.cfg
flossjtag.cfg lisa-l.cfg redbee-usb.cfg
flossjtag-noeeprom.cfg luminary.cfg sheevaplug.cfg
flyswatter2.cfg luminary-icdi.cfg signalyzer.cfg
flyswatter.cfg luminary-lm3s811.cfg signalyzer-lite.cfg
hilscher_nxhx10_etm.cfg minimodule.cfg stm32-stick.cfg
hilscher_nxhx500_etm.cfg neodb.cfg turtelizer2-revB.cfg
hilscher_nxhx500_re.cfg ngxtech.cfg turtelizer2-revC.cfg
hilscher_nxhx50_etm.cfg olimex-arm-usb-ocd.cfg vpaclink.cfg
hilscher_nxhx50_re.cfg olimex-arm-usb-ocd-h.cfg xds100v2.cfg
hitex_lpc1768stick.cfg olimex-arm-usb-tiny-h.cfg
hitex_str9-comstick.cfg olimex-jtag-tiny.cfg
$
• board - имеется в виду печатная плата, Circuit Board, PWA, PCB. Файлы плат содержат элементы инициализации, которые относятся к специфике конкретной платы. Они могут использовать конфигурационные файлы цели (target configuration files), поскольку один и тот же микроконтроллер может использоваться на многих отладочных платах, но поддержка внешних компонентов широко варьируется. Например, последовательность инициализации SDRAM для платы, или типа внешней памяти flash, и какой адрес она использует. Любая последовательность инициализации для разрешения работы внешней памяти flash или SDRAM должна находиться в файле конфигурации платы (board file). Платы также могут иметь несколько целей, конфигурируемых отдельно: два CPU, или CPU и FPGA.
$ ls board
actux3.cfg lpc1850_spifi_generic.cfg
am3517evm.cfg lpc4350_spifi_generic.cfg
arm_evaluator7t.cfg lubbock.cfg
at91cap7a-stk-sdram.cfg mcb1700.cfg
at91eb40a.cfg microchip_explorer16.cfg
at91rm9200-dk.cfg mini2440.cfg
at91rm9200-ek.cfg mini6410.cfg
at91sam9261-ek.cfg netgear-dg834v3.cfg
at91sam9263-ek.cfg olimex_LPC2378STK.cfg
at91sam9g20-ek.cfg olimex_lpc_h2148.cfg
atmel_at91sam7s-ek.cfg olimex_sam7_ex256.cfg
atmel_at91sam9260-ek.cfg olimex_sam9_l9260.cfg
atmel_at91sam9rl-ek.cfg olimex_stm32_h103.cfg
atmel_sam3n_ek.cfg olimex_stm32_h107.cfg
atmel_sam3s_ek.cfg olimex_stm32_p107.cfg
atmel_sam3u_ek.cfg omap2420_h4.cfg
atmel_sam3x_ek.cfg open-bldc.cfg
atmel_sam4s_ek.cfg openrd.cfg
balloon3-cpu.cfg osk5912.cfg
colibri.cfg phone_se_j100i.cfg
crossbow_tech_imote2.cfg phytec_lpc3250.cfg
csb337.cfg pic-p32mx.cfg
csb732.cfg propox_mmnet1001.cfg
da850evm.cfg pxa255_sst.cfg
digi_connectcore_wi-9c.cfg redbee.cfg
diolan_lpc4350-db1.cfg rsc-w910.cfg
dm355evm.cfg sheevaplug.cfg
dm365evm.cfg smdk6410.cfg
dm6446evm.cfg spear300evb.cfg
efikamx.cfg spear300evb_mod.cfg
eir.cfg spear310evb20.cfg
ek-lm3s1968.cfg spear310evb20_mod.cfg
ek-lm3s3748.cfg spear320cpu.cfg
ek-lm3s6965.cfg spear320cpu_mod.cfg
ek-lm3s811.cfg steval_pcc010.cfg
ek-lm3s811-revb.cfg stm320518_eval_stlink.cfg
ek-lm3s8962.cfg stm32100b_eval.cfg
ek-lm3s9b9x.cfg stm3210b_eval.cfg
ek-lm3s9d92.cfg stm3210c_eval.cfg
ek-lm4f120xl.cfg stm3210e_eval.cfg
ek-lm4f232.cfg stm3220g_eval.cfg
embedded-artists_lpc2478-32.cfg stm3220g_eval_stlink.cfg
ethernut3.cfg stm3241g_eval.cfg
glyn_tonga2.cfg stm3241g_eval_stlink.cfg
hammer.cfg stm32f0discovery.cfg
hilscher_nxdb500sys.cfg stm32f3discovery.cfg
hilscher_nxeb500hmi.cfg stm32f4discovery.cfg
hilscher_nxhx10.cfg stm32ldiscovery.cfg
hilscher_nxhx500.cfg stm32vldiscovery.cfg
hilscher_nxhx50.cfg str910-eval.cfg
hilscher_nxsb100.cfg telo.cfg
hitex_lpc1768stick.cfg ti_am335xevm.cfg
hitex_lpc2929.cfg ti_beagleboard.cfg
hitex_stm32-performancestick.cfg ti_beagleboard_xm.cfg
hitex_str9-comstick.cfg ti_beaglebone.cfg
iar_lpc1768.cfg ti_blaze.cfg
iar_str912_sk.cfg ti_pandaboard.cfg
icnova_imx53_sodimm.cfg ti_pandaboard_es.cfg
icnova_sam9g45_sodimm.cfg topas910.cfg
imx27ads.cfg topasa900.cfg
imx27lnst.cfg twr-k60f120m.cfg
imx28evk.cfg twr-k60n512.cfg
imx31pdk.cfg tx25_stk5.cfg
imx35pdk.cfg tx27_stk5.cfg
imx53loco.cfg unknown_at91sam9260.cfg
keil_mcb1700.cfg uptech_2410.cfg
keil_mcb2140.cfg verdex.cfg
kwikstik.cfg voipac.cfg
linksys_nslu2.cfg voltcraft_dso-3062c.cfg
lisa-l.cfg x300t.cfg
logicpd_imx27.cfg zy1000.cfg
$
• target - тут фокусируются на настройке чипа. Папка "target" представляет JTAG TAP-ы, встроенные в чип, которыми OpenOCD должна управлять, но не плату. Есть два общих типа целей - чипы ARM или чипы FPGA, CPLD. Когда в чипе есть несколько узлов TAP (это может быть для чипов, в которых встроены ядра ARM и DSP), то файл target config все эти TAP описывает.
$ ls target
aduc702x.cfg lpc1763.cfg
am335x.cfg lpc1764.cfg
amdm37x.cfg lpc1765.cfg
ar71xx.cfg lpc1766.cfg
at32ap7000.cfg lpc1767.cfg
at91r40008.cfg lpc1768.cfg
at91rm9200.cfg lpc1769.cfg
at91sam3ax_4x.cfg lpc1788.cfg
at91sam3ax_8x.cfg lpc17xx.cfg
at91sam3ax_xx.cfg lpc1850.cfg
at91sam3nXX.cfg lpc2103.cfg
at91sam3sXX.cfg lpc2124.cfg
at91sam3u1c.cfg lpc2129.cfg
at91sam3u1e.cfg lpc2148.cfg
at91sam3u2c.cfg lpc2294.cfg
at91sam3u2e.cfg lpc2378.cfg
at91sam3u4c.cfg lpc2460.cfg
at91sam3u4e.cfg lpc2478.cfg
at91sam3uxx.cfg lpc2900.cfg
at91sam3XXX.cfg lpc2xxx.cfg
at91sam4sd32x.cfg lpc3131.cfg
at91sam4sXX.cfg lpc3250.cfg
at91sam4XXX.cfg lpc4350.cfg
at91sam7se512.cfg lpc4350.cfg.orig
at91sam7sx.cfg mc13224v.cfg
at91sam7x256.cfg nuc910.cfg
at91sam7x512.cfg omap2420.cfg
at91sam9260.cfg omap3530.cfg
at91sam9260_ext_RAM_ext_flash.cfg omap4430.cfg
at91sam9261.cfg omap4460.cfg
at91sam9263.cfg omap5912.cfg
at91sam9.cfg omapl138.cfg
at91sam9g10.cfg pic32mx.cfg
at91sam9g20.cfg pxa255.cfg
at91sam9g45.cfg pxa270.cfg
at91sam9rl.cfg pxa3xx.cfg
atmega128.cfg readme.txt
avr32.cfg samsung_s3c2410.cfg
c100.cfg samsung_s3c2440.cfg
c100config.tcl samsung_s3c2450.cfg
c100helper.tcl samsung_s3c4510.cfg
c100regs.tcl samsung_s3c6410.cfg
cs351x.cfg sharp_lh79532.cfg
davinci.cfg smp8634.cfg
dragonite.cfg spear3xx.cfg
dsp56321.cfg stellaris.cfg
dsp568013.cfg stellaris_icdi.cfg
dsp568037.cfg stm32f0x_stlink.cfg
efm32_stlink.cfg stm32f1x.cfg
epc9301.cfg stm32f1x_stlink.cfg
faux.cfg stm32f2x.cfg
feroceon.cfg stm32f2x_stlink.cfg
fm3.cfg stm32f3x.cfg
hilscher_netx10.cfg stm32f3x_stlink.cfg
hilscher_netx500.cfg stm32f4x.cfg
hilscher_netx50.cfg stm32f4x_stlink.cfg
icepick.cfg stm32l.cfg
imx21.cfg stm32lx_dual_bank.cfg
imx25.cfg stm32lx_stlink.cfg
imx27.cfg stm32_stlink.cfg
imx28.cfg stm32w108_stlink.cfg
imx31.cfg stm32xl.cfg
imx35.cfg str710.cfg
imx51.cfg str730.cfg
imx53.cfg str750.cfg
imx6.cfg str912.cfg
imx.cfg swj-dp.tcl
is5114.cfg test_reset_syntax_error.cfg
ixp42x.cfg test_syntax_error.cfg
k40.cfg ti-ar7.cfg
k60.cfg ti_calypso.cfg
lpc1751.cfg ti_dm355.cfg
lpc1752.cfg ti_dm365.cfg
lpc1754.cfg ti_dm6446.cfg
lpc1756.cfg tmpa900.cfg
lpc1758.cfg tmpa910.cfg
lpc1759.cfg u8500.cfg
Просмотрите также другие библиотечные файлы, которые могут быть полезными. Например, это могут быть различные стандартные утилиты, или учитывающие специфику конкретного CPU.
Файл конфигурации пользователя openocd.cfg (user config file) может отменить опции, заданные во всех вышеперечисленных конфигурационных файлах interface, board, target путем установки переменных перед обращением к файлу target, или путем добавления команд, подходящих для каждой конкретной ситуации.
6.1. Файлы конфигурирования интерфейса (Interface Config Files)
Файл конфигурации пользователя может подключить любой файл интерфейса командой наподобие следующей:
source [find interface/FOOBAR.cfg]
Заранее составленный файл конфигурации интерфейса (preconfigured interface file) должен присутствовать для каждого адаптера отладки, который может использоваться в настоящий момент с OpenOCD. Однако возможно, что некоторые из этих config-файлов использовались только разработчиком, который создал его. Отдельный раздел предоставляет информацию о том, как делать такие настройки, см. раздел [8. Конфигурация адаптера отладки (Debug Adapter Configuration)]. Ознакомьтесь с исходным кодом OpenOCD (и руководством разработчика Developer’s Guide), если Вы столкнулись с новым аппаратным интерфейсом, и Вам нужен драйвер для него.
6.2. Файлы конфигурирования платы (Board Config Files)
Конфигурационный файл пользователя должен использовать эти файлы (чаще один, иногда несколько) командой наподобие следующей:
source [find board/FOOBAR.cfg]
Назначение board config file - объединить в один пакет все о плате, что должен знать файл конфигурации пользователя. В общих чертах файл конфигурации board должен иметь в себе (если такая возможность представлена):
1. Один или большее количество операторов source [target/...cfg].
2. Конфигурацию NOR flash (см. раздел [12. Команды FLASH]).
3. Конфигурацию NAND flash (см. раздел [14. Команды NAND Flash]).
4. Обработчики сброса цели (target reset handlers) для SDRAM и конфигурации ввода/вывода (I/O).
5. Конфигурацию сброса адаптера JTAG (см. раздел [9. Конфигурация сброса (Reset Configuration)]).
6. Все, что не относится к внутренней аппаратуре чипа.
Стандартные особенности target chip относятся к файлам конфигурации target, не к файлам конфигурации board. Так, например, обработчик события reset-init должен знать параметры специфичного для платы генератора или узла PLL, которые передаются коду утилиты, отвечающему за специфику target. Самая сложная задача файла board config - создание таких обработчиков события инициализации при сбросе (reset-init event handler). Задайте такие обработчики последними, после того, как проверите работу остальных частей конфигурации платы.
6.2.1. Взаимосвязь между файлами конфигурации
В дополнение к коду утилит, специфичному для target, другой путь обмена между файлами конфигурации board и target состоит в соглашении по использованию некоторых переменных.
Полная версия языка Tcl/Tk поддерживает пространства имен (namespaces), но урезанная версия Jim-Tcl этого не делает (все переменные глобальные). Таким образом, в OpenOCD нужно следовать правилу: переменные, которые начинаются с символа подчеркивания, являются по природе временными, и их можно модифицировать и использовать как угодно в пределах файла конфигурации target. Сложные файлы board config могут делать действия наподобие следующих (для платы с тремя чипами):
# Chip #1: PXA270 на стороне сети, big endian
set CHIPNAME network
set ENDIAN big
source [find target/pxa270.cfg]
# при выходе: _TARGETNAME = network.cpu
# другие команды могут обращаться к "network.cpu" target.
$_TARGETNAME configure .... события для этого CPU..
# Chip #2: PXA270 на стороне video, little endian
set CHIPNAME video
set ENDIAN little
source [find target/pxa270.cfg]
# при выходе: _TARGETNAME = video.cpu
# другие команды могут обращаться к "video.cpu" target.
$_TARGETNAME configure .... события для этого CPU..
# Chip #3: Xilinx FPGA для дополнительной логики
set CHIPNAME xilinx
unset ENDIAN
source [find target/spartan3.cfg]
Этот пример очень упрощен, потому что он не показывает flash memory и обработчики события reset-init для инициализирования внешней DRAM или (подразумевается что это нужно) загрузку конфигурации в FPGA. Такие особенности обычно нужны для работы на низком уровне (low level) со многими платами, где под низким уровнем подразумевается программная инициализация платы, без которой плата не будет нормально работать. (Это общая причина, по которой нужны инструменты JTAG. Другая причина - работа с системами на основе микроконтроллера, когда нет другой поддержки отладки, кроме JTAG.)
Конфигурационные файлы target могут также иметь функции утилит экспорта для конфигурационных файлов board и user config. Такие функции должны использовать префиксы имен, чтобы помочь избежать коллизий имен.
Файлы board могут также получать входные переменные из конфигурационных файлов. Например, может быть установка J4_JUMPER, используемая для идентификации того, какой вид flash-памяти используется на плате, или как установлены тактовые частоты и периферийные устройства.
6.2.2. Соглашение об именовании переменной (Variable Naming Convention)
Большинство плат имеют только один чип. Однако, могут быть платы с несколькими чипами (как было показано в предыдущем примере). Соответственно мы рекомендуем обусловится принципами именования переменных, связанных с разными файлами target.cfg, чтобы предоставить логичное конфигурирование и файлы board могли переопределить значения по умолчанию, заданные target.
Входные данные для файлов конфигурации target включают:
• CHIPNAME ... Это дает имя для всего чипа, и используется как часть имени с точками от идентификатора TAP. В то время как значение по умолчанию предоставлено производителем чипа, файлам board может потребоваться возможность различать отдельные экземпляры чипа.
• ENDIAN ... По умолчанию little, хотя некоторые чипы могут жестко использовать big (имеется в виду little endian, big endian). Для чипов, которые не могут поменять порядок байт (endianness), эта переменная не нужна.
• CPUTAPID ... Когда OpenOCD проверяет цепочку JTAG [1], он может проверить соответствие чипа значению регистра JTAG IDCODE. Файл target может содержать в себе одно или большее количество значений по умолчанию, но иногда чип на плате будет использовать отличающийся ID (возможно, свою новую ревизию).
Вывод из файлов target config включает:
• _TARGETNAME ... По соглашению, эта переменная создается скриптом конфигурации target. Файл конфигурации board может использовать эту переменную для конфигурирования сущностей наподобие скрипта "reset init", или других вещей, специфичных для этой платы и этой target. Если у чипа 2 (или большее количество) target, то они именуются _TARGETNAME0, _TARGETNAME1, ... и так далее.
6.2.3. Обработчик события инициализации сброса (reset-init Event Handler)
Файлы конфигурации board запускаются на стадии конфигурирования OpenOCD; они не могут использовать TAP-ы или target-ы, пока они не будут полностью настроены. Это означает, что Вы не можете записывать в память или получить доступ к регистрам чипа; Вы даже не можете проверить имеется ли у чипа flash. Такая настройка выполняется позже в обработчиках события, из которых обработчик инициализации сброса (target reset-init handler) один из самых важных.
За исключением микроконтроллеров (которые имеют встроенную память, не требующую инициализации), базовой функцией reset-init event handler является настройка flash и DRAM, как это обычно делают бутлоадеры. Микроконтроллеры не всегда используют бутлоадеры; программа в них может быть запущена сразу из встроенной памяти flash и SRAM. Но они также могут использовать один из этих обработчиков, если это понадобится разработчику.
Внимание: поскольку это очень зависит от специфики платы и специфики чипа, здесь не приведено примеров. Вместо этого просмотрите файлы board config, которые поставляются с OpenOCD. Если используете бутлоадер, то Вам может помочь его исходный код; то же самое относится к файлам конфигурации для других инструментов JTAG (см. раздел 6.4. Трансляция конфигурационных файлов).
Некоторый код может быть один и тот же для разных плат. Например, настройка контроллера DRAM часто не отличается друг от друга за исключением ширины используемой шины (16 или 32 бита?) и таймингов памяти, так что повторно используемая процедура TCL, загружаемая из файла target.cfg, может получать эти данные в качестве параметров. То же самое относится к настройке генератора, PLL и тактов, и к запрету watchdog. Код имеет ясную структуру, и имеет комментарии, чтобы помочь другим разработчикам. (Вы можете быть следующим, кто попробует повторно использовать код инициализации!)
Последнее, что должен нормально выполнять reset-init handler - проверка, что память flash была сконфигурирована. Для большинства чипов это нужно сделать пока связанная target приостановлена, либо потому что нужно предотвратить доступ к памяти со стороны CPU, когда к памяти обращается JTAG - чтобы избежать конфликта.
6.2.4. Тактовая частота JTAG (JTAG Clock Rate)
Перед тем, как Ваш обработчик reset-init настроит PLL и тактирование, может потребоваться работать на пониженной тактовой частоте JTAG, см. раздел 8.4. Скорость JTAG (JTAG Speed). Затем Вы увеличите эту скорость, после того как Ваш обработчик сделает возможным использование повышенной тактовой частоты JTAG. Когда изначальная низкая скорость зависит от конкретной платы, например потому что зависит от скорости генератора на плате, то возможно настройка должна быть в файле board config; если это специфика target, то настройка должна быть в файле target config.
Для большинства основанных на архитектуре ARM процессоров повышенные тактовые частоты4 равны 1/6 от тактовой частоты CPU; или 1/8 для ядер ARM11. Обратитесь к документации на чип, чтобы определить пиковую тактовую частоту JTAG, и частота должна быть выбрана ниже пиковой.
Примечание 4: подробности см. в FAQ http://www.arm.com/support/faqdev/4170.html.
Внимание: для большинства ARM детектирование тактов JTAG соединено с тактами ядра, так что к примеру программа, которая использует инструкцию WFI, может блокировать доступ к JTAG. Адаптивное тактирование JTAG предоставляет некоторый обход проблемы, но более полное решение просто исключает использование такой инструкции с отладчиками JTAG.
Если и чип, и плата поддерживают адаптивное тактирование, используйте команду jtag_rclk в том случае, когда вместе с платой используете адаптер JTAG, который также поддерживает адаптивное тактирование. Иначе используйте adapter_khz. Установите медленную скорость в начале последовательности сброса, и быструю скорость как только такты будут работать на полной скорости.
6.2.5. Процедура init_board
Концепция процедуры init_board очень похожа на init_targets (см. раздел 6.3.6. Процедура init_targets) - это замена "линейных" конфигурационных скриптов. Эта процедура подразумевает свое выполнение, когда OpenOCD входит в стадию постоянной работы (run stage) после init_targets, см. раздел 7.2. Вход в состояние постоянной работы (Entering the Run Stage Stage). Идея иметь отдельные процедуры init_targets и init_board в том, чтобы позволить первой конфигурировать все, что специфично для target (внутренняя память flash, RAM, и т. д.) и второй конфигурировать все, что относится к плате (сигналы сброса, частота чипа, reset-init event handler, внешняя память и т. д.). Дополнительно "линейный" файл board config чаще всего не загрузится, когда файл target config использует схему init_targets ("линейный" скрипт, выполняемый перед init и init_targets - после), так что разделение этих двух конфигурационных стадий очень удобно. Как самый простой способ избежать этой проблемы - сконвертировать файл board config для использования процедуры init_board. Скрипты board config не нуждаются в переназначении init_targets, заданных в файлах target config, когда нужно только добавить некоторые специфические особенности.
Как и init_targets, процедура init_board может быть переназначена на скрипте "следующего уровня" (который поставляет оригинал), что позволяет улучшенное повторное использование кода.
### board_file.cfg ###
# Исходный файл target, который выполняет основную конфигурацию
# в init_targets
source [find target/target.cfg]
proc enable_fast_clock {} {
# разрешает использование быстрой тактовой частоты платы
# конфигурирует чип для использования
}
# инициализация только специфики платы - сброс, такты, частота адаптера
proc init_board {} {
reset_config trst_and_srst trst_pulls_srst
$_TARGETNAME configure -event reset-init {
adapter_khz 1
enable_fast_clock
adapter_khz 10000
}
}
6.3. Файлы конфигурирования цели (Target Config Files)
Файлы board config обмениваются с файлами target config, используя соглашение именования, которое было изложено ранее, и может обращаться к одному или нескольким файлам target config примерно так:
source [find target/FOOBAR.cfg]
Назначение файла target config - объединить в себе все, касающееся используемого чипа, что должны знать файлы board config. В общем файлы target должны содержать:
1. Установки по умолчанию.
2. Добавление TAP-ов к цепочке сканирования (JTAG).
3. Добавление CPU targets (включает поддержку GDB).
4. Поддержка специфических особенностей CPU/чипа/ядра.
5. Подключение встроенной в чип памяти flash.
Основное правило - файлы target настраивают только чип. Для микроконтроллера это будет часто только один TAP, который подключен к CPU (нужен для GDB target), и встроенная память flash.
Более сложные чипы могут включать в себе несколько TAP-ов, и файлу target config может потребоваться определить их все, перед тем как OpenOCD сможет обмениваться данными с чипом. Например, некоторые чипы для (мобильных) телефонов цепочки сканирования JTAG, состоящих из ядра ARM для операционной системы, DSP, другое ядро ARM, встроенное в систему обработки изображения, и другие системы обработки на основе процессоров.
6.3.1. Обычный код шаблона (Default Value Boiler Plate Code)
Все файлы конфигурации target должны стартовать с кодом, наподобие приведенного ниже, что позволяет файлам board config учесть специфические отличительные свойства окружения, в котором должны быть настроены все возможности.
# Платы могут перезадавать имена чипа, возможно базируясь на их роли,
# но значение по умолчанию должно соответствовать тому, что использует вендор
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME sam7x256
}
# Поменять это могут только те, цели, что используют ENDIAN
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN little
}
# Идентификаторы TAP могут меняться в соответствии с ядром чипа, например
# при появлении полей новой ревизии (здесь это "3"). Выберите хорошее значение
# по умолчанию; Вы можете передать такие идентификаторы команде "jtag newtap".
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
set _CPUTAPID 0x3f0f0f0f
}
Помните: файлы board config могут подключать несколько файлов target config, или несколько раз подключать один и тот же файл target (при этом как минимум должно измениться CHIPNAME).
Аналогично файл конфигурации target должен определять _TARGETNAME (или _TARGETNAME0 и т. п.), и использовать их позже, когда определяются debug targets:
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm7tdmi -chain-position $_TARGETNAME
6.3.2. Добавление TAP-ов в цепочку JTAG (JTAG Scan Chain)
После того, как "умолчания" назначены, добавьте TAP-ы каждого чипа к цепочке JTAG. См. раздел [10. Декларирование TAP] и соглашение именования для TAP-ов.
В самом простом (и самом распространенном) случае чип имеет только один TAP, обычно для CPU или FPGA. Конфигурационный файл для микроконтроллера Atmel AT91SAM7X256 частично будет выглядеть примерно так:
jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID
Плата с двумя такими чипами должна иметь возможность вызвать такой конфигурационный файл дважды, каждый раз с другим значением CHIPNAME, и добавить разные TAP-ы для каждого вызова.
Если здесь указаны ненулевые значения -expected-id, OpenOCD попробует проверить актуальный tap id на эти значения. Если не было совпадения, выведется сообщение об ошибке, которое может помочь разобраться в проблеме конфигураций OpenOCD.
JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f
(Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)
ERROR: Tap: sam7x256.cpu - Expected id: 0x12345678, Got: 0x3f0f0f0f
ERROR: expected: mfg: 0x33c, part: 0x2345, ver: 0x1
ERROR: got: mfg: 0x787, part: 0xf0f0, ver: 0x3
Есть также более сложные примеры с чипами, у которых несколько TAP-ов. Некоторые из них могут выглядеть похоже на следующие:
• target/omap3530.cfg – с запрещенными ARM и DSP, плюс JRC для разрешения их.
• target/str912.cfg – с flash, CPU и boundary scan.
• target/ti_dm355.cfg – с ETM, ARM и JRC (этот JRC в настоящий момент не используется).
6.3.3. Добавление целей CPU (Add CPU targets)
После добавления TAP для CPU Вы должны настроить его так, чтобы GDB и другие команды могли его использовать. См. раздел [11. Конфигурация CPU]. Для вышеуказанного примера с at91sam7 команда может выглядеть наподобие таких (имейте в виду, что $_ENDIAN не нужна, поскольку по умолчанию OpenOCD работает в режиме little endian, и этот чип не поддерживает изменение порядка байт):
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm7tdmi -chain-position $_TARGETNAME
Рабочие области (work areas) - это маленькие блоки RAM, связанные с CPU target-ами. Они используются OpenOCD для ускорения загрузки, и для загрузки маленьких кусочков кода для программирования чипов flash. Если чип включает форму "on-chip-ram", то если Вы можете, то задайте рабочую область. Возвращаясь к тому же at91sam7 в качестве примера, это может выглядеть так:
$_TARGETNAME configure -work-area-phys 0x00200000
-work-area-size 0x4000 -work-area-backup 0
6.3.4. Определение CPU target-ов, работающих в SMP
После установки target-ов Вы можете задать список target-ов, работающих в SMP.
set _TARGETNAME_1 $_CHIPNAME.cpu1
set _TARGETNAME_2 $_CHIPNAME.cpu2
target create $_TARGETNAME_1 cortex_a -chain-position $_CHIPNAME.dap
-coreid 0 -dbgbase $_DAP_DBG1
target create $_TARGETNAME_2 cortex_a -chain-position $_CHIPNAME.dap
-coreid 1 -dbgbase $_DAP_DBG2
#определение 2 целей, работающих в smp.
target smp $_CHIPNAME.cpu2 $_CHIPNAME.cpu1
Вышеуказанный пример на cortex_a показывает 2 CPU, работающих в SMP. В SMP создается только один экземпляр GDB и:
• устанавливается набор аппаратных точек останова (hardware breakpoint) с той же самой точкой останова для всех target в списке.
• триггеры команды halt, которые останавливают все target в списке.
• триггеры команды resume записи контекста и перезапуска всех target в списке.
• точка останова: target остановлен по breakpoint, отображаемой в сессии GDB.
• реализованы выделенные пакеты последовательного протокола GDB для переключения/запроса target, отображаемого в сессии GDB, см. раздел 21.5. Использование OpenOCD SMP с GDB.
Поведение SMP может быть запрещено/разрешено динамически. На cortex_a реализованы следующие команды.
• cortex_a smp_on : разрешить режим SMP, поведение как было описано ранее.
• cortex_a smp_off : запрет режима SMP, в сессии GDB будет отображена одна текущая target, только эта таргет теперь будет управляться сессией GDB. Это поведение полезно во время загрузки системы (system boot up).
• cortex_a smp_gdb : отображение/фиксация идентификатора ядра, отображаемого в сессии GDB - см. в следующем примере.
>cortex_a smp_gdb
gdb coreid 0 -> -1
#0 : в сессии GDB отображается coreid 0,
#-> -1 : следующее resume триггеров выполняет реальное возобновление
> cortex_a smp_gdb 1
gdb coreid 0 -> 1
#0 : в сессии GDB отображается coreid 0,
#->1 : следующее resume отображает coreid 1 для GDB
> resume
> cortex_a smp_gdb
gdb coreid 1 -> 1
#1 : в сессии GDB отображается coreid 1,
#->1 : следующее resume отображает coreid 1 для GDB
> cortex_a smp_gdb -1
gdb coreid 1 -> -1
#1 : в сессии GDB отображается coreid 1,
#->-1 : следующее resume триггеров выполняет реальное возобновление
6.3.5. Настройка сброса чипа (Chip Reset Setup)
Как правило, Вы должны поместить команду reset_config в файл board. Чаще всего нужно подумать о том, как сброс должен быть подстроен в зависимости от аппаратуры платы.
Некоторые чипы имеют особенные методы для управления сигналами TRST и SRST. В бесполезном случае они определены чипом и не изменяются разводкой платы. Например, некоторые чипы не могут поддержать отладку JTAG без обоих сигналов.
Если можете, предоставьте обработчик события reset-assert. Такой обработчик использует операции JTAG для сброса цели, что позволяет использовать этот target config использовать в системах, которые не предоставили опционально сигнал SRST, или на системах, где Вы не хотите вообще сбрасывать все target-ы. Такой обработчик может записывать в регистры чипа, чтобы принудительно произвести сброс, используя для этого JRC (предпочтительно – target может заклинить!), или запустить срабатывание таймера watchdog. (Для Cortex-M target-ов это не требуется. Драйвер target знает, как использовать триггер NVIC reset, когда SRST недоступен.)
Некоторые чипы нуждаются в специальном внимании при обработке сброса, если они делают это с использованием JTAG. Пример может понадобиться для отправки некоторых команд после того, как TAP target-ов будет сброшен, предоставляя обработчик события reset-deassert-post, который записывает в регистр чипа, чтобы сообщить, что отладка JTAG завершена. Другой повторно реконфигурировал бы watchdog, так чтобы он остановил счет, когда ядро остановлено в отладчике.
Ограничения на тактирование JTAG часто меняются во время сброса, и в некоторых случаях файлы target config (вместо файлов board config) будут правильным местом для размещение обработки некоторых этих проблем. Например, сразу после сброса некоторые чипы запускаются на пониженной тактовой частоте по сравнению с той, которая будет использоваться потом. Это означает, что после сброса (и потенциально как только OpenOCD стартует) они могут использовать пониженную частоту JTAG по сравнению с той, что будет позже. См. раздел 8.4. Скорость JTAG.
Важно: когда Вы отлаживаете код, который запускается после сброса чипа, такие проблемы критичны. В частности, если Вы наблюдаете неустойчивые сбои, когда OpenOCD проверяет цепочку JTAG (scan chain) после сброса, посмотрите, как Вы настроили тактирование JTAG.
6.3.6. Процедура init_targets
Файлы target config могут быть либо "линейными" (скрипт, который выполняется строка-за-строкой при парсинге на стадии конфигурации, см. раздел 7.1. Стадия конфигурации), либо могут содержать специальную процедуру, называемую init_targets, которая может быть выполнена, когда происходит вход в стадию запуска run stage (после парсинга всех конфигурационных файлов или после команды init, см. раздел 7.2. Вход в стадию запуска (Run Stage)). Такая процедура может быть перезадана скриптом "следующего уровня" (который обращается к оригинальному). Эта концепция может упростить повторное использование кода, когда базовый файл target config предоставляет стандартные процедуры конфигурации и процедуру init_targets, которая может быть задействована и расширена или изменена "более специфичным" файлом target config. Это невозможно с "линейными" скриптами конфигурации, потому что обращение к ним выполняет каждую из команд инициализации, которые они предоставляют.
### generic_file.cfg ###
proc setup_my_chip {chip_name flash_size ram_size} {
# базовая процедура инициализации ...
}
proc init_targets {} {
# инициализирует стандартный чип с 4 килобайт flash и 1 килобайт RAM
setup_my_chip MY_GENERIC_CHIP 4096 1024
}
### specific_file.cfg ###
source [find target/generic_file.cfg]
proc init_targets {} {
# инициализирует специфичный чип с 128 килобайт flash и 64 килобайт RAM
setup_my_chip MY_CHIP_WITH_128K_FLASH_64KB_RAM 131072 65536
}
Простой путь - преобразовать "линейные" конфигурационные файлы версию init_targets для того чтобы закрыть каждую строку "кода" (например, не исходные команды, процедуры и т. п.) в этой процедуре.
Пример такой схемы см. в файлах target config LPC2000.
Процедура init_boards имеет концепцию на основе файлов board config (см. раздел 6.2.5. Процедура init_board).
6.3.7. Хаки, специфичные для ядра ARM
Если чип имеет DCC, разрешите его. Если чип ARM9 со специальной возможностью высокоскоростной загрузки - разрешите это.
Если имеются, то MMU, MPU и CACHE надо запретить.
Некоторые ядра ARM оборудованы поддержкой трассировки, которая разрешает анализировать инструкции и активность шины данных. Активность трассировки управляется через "Embedded Trace Module" (ETM) на одной из цепочек JTAG ядра. ETM выдает объемные данные через "trace port". (См. раздел 17.1. Аппаратная трассировка ARM.) Если Вы используете внешний порт трассировки, сконфигурируйте его в Вашем файле board config. Если Вы используете встроенный в чип "Embedded Trace Buffer" (ETB), сконфигурируйте его в Вашем файле target config.
etm config $_TARGETNAME 16 normal full etb
etb config $_TARGETNAME $_CHIPNAME.etb
6.3.8. Конфигурация внутренней памяти Flash
Это применимо ТОЛЬКО ДЛЯ МИКРОКОНТРОЛЛЕРОВ, которые имеют встроенную память flash. Никогда не задавайте в файле конфигурации target любой тип flash, которая является внешней по отношению к чипу. (Например, BOOT flash на сигнале Chip Select 0.) Информация о внешней flash поставляется в файле board
- но ни в коем случае не в файле TARGET (который относится к чипу).
Примеры:
• at91sam7x256 - имеет 256K flash, YES разрешает её.
• str912 - имеет внутреннюю flash, YES разрешает её.
• imx27 - использует boot flash на CS0 - это должно быть указано в файле board.
• pxa270 - также CS0 flash - это должно быть указано в файле board.
6.4. Трансляция конфигурационных файлов
Если у Вас есть конфигурационный файл для другого аппаратного отладчика или тулсета (Abatron, BDI2000, BDI3000, CCS, Lauterbach, Segger, Macraigor, и т. д.), транслирование его в синтаксис OpenOCD часто делается по весьма очевидному и прямому алгоритму. Часто самая сложная часть - создание скрипта конфигурации для последовательности reset init, где должны быть настроены соответственно PLL, DRAM и т. п.
Есть трюк, когда Вы можете при трансляции создать маленькие процедуры Tcl, чтобы транслировать синтаксис исходного конфига в синтаксис OpenOCD. Это может помочь избежать допускаемых вручную ошибок при трансляции, и также упростит последующие преобразования других скриптов.
Пример быстрого преобразования аргументов для простого поиска и замены:
# Lauterbach syntax(?)
#
# Data.Set c15:0x042f %long 0x40000015
#
# Процедура ниже, когда синтаксис OpenOCD.
#
# setc15 0x01 0x00050078
proc setc15 {regs value} {
global TARGETNAME
echo [format "set p15 0x%04x, 0x%08x" $regs $value]
arm mcr 15 [expr ($regs>>12)&0x7]
[expr ($regs>>0)&0xf] [expr ($regs>>4)&0xf]
[expr ($regs>>8)&0x7] $value
}
[7. Конфигурация демона (Daemon Configuration)]
Здесь команды в общем случае находятся в файле openocd.cfg, и они используются для указания, какие используются порты TCP/IP и как поддерживается GDB.
7.1. Стадия конфигурирования
Когда стартует процесс сервера OpenOCD, то он переходит в стадию конфигурирования, на которой могут быть выполнены некоторые команды. Обычно команды конфигурирования доступны только из скриптов запуска (startup scripts).
В этом руководстве определение команд конфигурации представлено как Config Command, не как команда Command, которая может быть выдана интерактивно. Команда времени выполнения help также выдает подсказку по командам конфигурации, которые могут быть выполнены в любое время.
Эти команды конфигурации включают в себя декларирование TAP-ов, банков flash, используемого для обмена интерфейса JTAG, и другие базовые настройки. Сервер должен выйти из стадии конфигурации до того, как он получит доступ к TAP-ам или активирует их. После выхода из этой стадии команды конфигурации могут больше не выдаваться.
7.2. Вход в стадию запуска (Run Stage)
Первое, что делает OpenOCD после выхода из стадии конфигурации - проверка, что она может передавать данные по цепочке JTAG scan chain (просматривает список TAP-ов), в соответствии с тем, как она была сконфигурирована. Если ожидаемые TAP-ы не найдены, то будет выдано предупреждение, или если найдены TAP-ы, которые не подразумевались. В этой точке Вы не должны видеть ошибок. Если же ошибки есть, то исправьте их корректированием команд, которые используете для конфигурирования сервера. Общие ошибки включают использование начальной скорости JTAG, которая слишком высока, и не предоставлены верные значения IDCODE для TAP-ов в JTAG scan chain.
Как только OpenOCD вошла в run stage, будут доступны некоторые команды. Их количество связано с декларированными Вами debug target-ами. Например, команда mww не будет доступна, пока target не будет полностью успешно инициализирована. Если хотите использовать эти команды, Вам может понадобиться принудительно войти в run stage.
init [Config Command]
Эта команда обрывает стадию конфигурирования и делает переход к стадии запуска (Run Stage). Это помогает, когда Вам нужны скрипты запуска для задач управления, каких как сброс target, программирование flash, и т. д. Для сброса CPU при запуске добавьте "init" и "reset" в конец скрипта конфигурации или в конец командной строки OpenOCD (используя ключ командной строки -c).
Если эта команда не появляется в любом файле запуска/конфигурации, OpenOCD выполнит эту команду для Вас после обработки всех конфигурационных файлов и/или опций командной строки.
Внимание: эта команда нормально появляется близко к концу Вашего файла openocd.cfg, чтобы заставить OpenOCD "инициализировать" и привести в готовность target-ы. Например, если Ваш openocd.cfg нуждается в чтении/записи памяти target, то init должен встретиться перед командами чтения/записи памяти. Это включает nand probe.
jtag_init [Overridable Procedure, перезадаваемая процедура]
Это запускает старт сервера для проверки, может ли он работать с цепочкой JTAG (просмотр списка TAP-ов), которая была сконфигурирована.
Реализация по умолчанию сначала пытается выполнить jtag arp_init, которая использует только легкий сброс JTAG перед проверкой цепочки. В случае неудачи она делает новую попытку, используя более жесткий сброс из перезадаваемой процедуры init_reset.
Реализации должны быть проверены на JTAG scan chain перед тем, как произойдет возврат. Это делается вызовом jtag arp_init (или jtag arp_init-reset).
7.3 Порты TCP/IP
Сервер OpenOCD принимает сетевые команды с некоторыми синтаксисами. Каждый синтаксис использует отдельный порт TCP/IP, который можно задать только при конфигурировании (перед тем, как эти порты будут открыты для прослушивания).
По некоторым причинам, включая безопасность, Вы можете захотеть предотвратить удаленный доступ с использованием одного или большего количества из этих портов. Тогда просто укажите соответствующие номера портов равными 0. Если Вы полностью запретите доступ через TCP/IP, то (на Linux) Вам понадобится опция командной строки -pipe.
gdb_port [number] [Command]
Обычно gdb прослушивает порт TCP/IP, но GDB может также обмениваться данными через так называемые именованные каналы (stdin/out или named pipes). Имя "gdb_port" является укоренившимся, потому что оно покрывает обычно больше 90% нормальных случаев использования.
Без аргументов выведется сообщение о порте GDB. Слово "pipe" означает прослушивание stdin output в stdout, целое число задает базовый номер порта, "disable" запрещает сервер gdb.
Когда используется "pipe", также используется вывод в лог как перенаправление в лог-файл, чтобы не забивать сообщениями каналы stdin/out.
Опция -p/–pipe устарела и при её использовании выводится предупреждение, что для неё есть эквивалент передаваемый в -c "gdb port pipe; log output openocd.log".
Любая другая строка интерпретируется как именованный канал (named pipe) для прослушивания. Output pipe (выходной канал) имеет то же имя как и input pipe (входной канал), но с добавлением ’o’, например /var/gdb, /var/gdbo.
Порт GDB port для первой target будет равен базовому порту, вторая target будет прослушиваться gdb на базовом порте + 1, и так далее. Когда порт не указан на стадии конфигурации, то номер порта по умолчанию 3333.
tcl_port [number] [Command]
Указывает или запрашивает номер порта, используемый для упрощенного соединения RPC, которое может использоваться клиентами для выдачи команд TCL и получения ответов от системы Tcl. Предназначение - машинный интерфейс. Когда порт не указан на стадии конфигурации, номер порта по умолчанию 6666.
telnet_port [number] [Command]
Указывает или запрашивает номер порта, который будет прослушиваться для входящих соединений telnet. Этот порт предназначен для взаимодействия с человеком через команды TCL. Когда порт не указан на стадии конфигурации, номер порта по умолчанию 4444. Когда в качестве номера порта указан 0, то этот порт не активируется.
7.4. Конфигурация GDB
Вы можете переконфигурировать некоторые аспекты поведения GDB если это необходимо. Один из них, упомянутый здесь - static (статический) и global (глобальный). См. раздел 11.3. Конфигурирование Target о том, как индивидуально конфигурировать target-ы. См. раздел 11.5. События цели (Target Events) о том, как конфигурировать специфичные для target обработки событий.
gdb_breakpoint_override [hard|soft|disable] [Command]
Принудительно задать тип точки останова для команд gdb break. Эта опция поддерживает графические интерфейсы GDB (GUI), которые не отличают аппаратный тип точки останова (hard breakpoint) от программного (soft breakpoint), если поведение по умолчанию для OpenOCD и GDB не является существенным. GDB обычно использует аппаратные точки останова, если карта памяти (memory map) была настроена для регионов flash.
gdb_flash_program (enable|disable) [Config Command]
Установите для того, чтобы разрешить OpenOCD программировать память flash, когда принят пакет vFlash. Поведение по умолчанию - разрешено.
gdb_memory_map (enable|disable) [Config Command]
Установите для того, чтобы разрешить OpenOCD отправить отправить конфигурацию памяти к GDB, когда получен соответствующий запрос. GDB узнает, где устанавливать аппаратные точки останова, и сможет программировать flash командой GDB load. gdb_flash_program enable должно также быть разрешено для работы программирования flash. Поведение по умолчанию - разрешено, enable. См. команду gdb flash program.
gdb_report_data_abort (enable|disable) [Config Command]
Указывает, будут ли обрывы данных (data aborts) приводить к сообщениям об ошибке пакетов чтения памяти GDB. Поведение по умолчанию - запрещено; используйте enable, чтобы увидеть сообщения об этих ошибках.
7.5. Опрос событий (Event Polling)
Аппаратные отладчики являются частями асинхронных систем, где важные события могут произойти в любое время. Серверу OpenOCD нужно детектировать некоторые из этих событий, чтобы он мог сообщать о событиях через командную строку TCL или для GDB. Примеры таких событий включают в себя:
• Одна из target-ов может остановить работу ... возможно, сработала точка останова по коду, или был останов на data watchpoint, или она остановила сама себя.
• Сообщения могут быть отправлены через каналы "debug message" ... многие target-ы поддерживают такие сообщения, отправленные через JTAG, для того чтобы они были приняты пользователем отладчика или инструментария.
• Пропадание питания ... некоторые адаптеры могут детектировать такие события.
• Сбросы не выдаются через JTAG ... такие источники сброс могут включать нажатия на кнопку сброс или другую аппаратуру, иногда даже встроенную в саму target (возможно через watchdog).
• Иногда инструменты отладки поддерживают событие наподобие "trace buffer full" ("буфер трассировки полон", чтобы он мог быть быстро опустошен) или другие сигналы (связанные с поведением кода).
Такие события не могут быть переданы через стандартные сигналы JTAG. Однако многие соглашения для соединителей JTAG [5] включают детектирование уровня напряжения и сигнала сброса системы (SRST). Некоторые коннекторы включают инструментальные сигналы, которые могут подразумевать события, когда эти сигналы - входы.
Обычно OpenOCD нуждается в периодической проверке таких событий либо просматривая статус сигналов на коннекторе JTAG, либо отправкой синхронных запросов JTAG "tell me your status" (выдай мне твой статус) различным активным target-ам. Для этого имеется команда для управления и опроса, которая обычно выполняется в фоновом процессе.
poll [on|off] [Command]
Опрос текущей цели на её текущее состояние. См. также команду target curstate в разделе 11.4. Другие команды $target_name). Если такая target находится в режиме отладки, выводится информация о текущем состоянии, специфичная для архитектуры. Опциональный параметр позволяет разрешить и запретить фоновый опрос.
Вы можете использовать это из шелла команд TCL или из GDB используя команду опроса монитора (monitor poll command). Оставьте фоновый опрос разрешенным, когда используете GDB.
> poll
background polling: on
target state: halted
target halted in ARM state due to debug-request,
current mode: Supervisor
cpsr: 0x800000d3 pc: 0x11081bfc
MMU: disabled, D-Cache: disabled, I-Cache: enabled
>
[8. Конфигурация адаптера отладки (Debug Adapter Configuration)]
Корректно установленный OpenOCD имеет доступ к адаптеру отладки через Вашу операционную систему. Для реализации этого используются команды Tcl для выбора - какой адаптер использовать и как его использовать.
Внимание: поскольку OpenOCD стартует, фокусируясь полностью на JTAG, Вы можете встретить неверные предположения, что JTAG является единственным используемым транспортным протоколом. Имейте в виду, что свежие версии OpenOCD удалили это ограничение. JTAG остается наиболее функциональным транспортом по сравнению с другими. Другие транспорты не поддерживают операции boundary scan, или могут иметь специфику, предоставленную вендором чипа. Некоторые можно использовать только для программирования памяти flash вместо поддержки еще и отладки.
Адаптеры отладки / интерфейсы / донглы обычно конфигурируются командами в файле конфигурации интерфейса, который вызывается из Вашего файла openocd.cfg, или через опцию командной строки -f interface/имя_адаптера.cfg. Пример:
source [find interface/olimex-jtag-tiny.cfg]
Эти команды говорят OpenOCD, какой тип у Вашего адаптера JTAG, и как осуществить обмен с ним. В некоторых случаях все настолько просто, что Вам нужно только сказать, какой драйвер использовать:
# jlink interface
interface jlink
Многие адаптеры нуждаются в несколько более сложной конфигурации, чем эта.
8.1. Конфигурация интерфейса (Interface Configuration)
Команда interface говорит OpenOCD, какой тип адаптера отладки Вы используете. В зависимости от типа адаптера Вам может понадобиться использовать одну или несколько дополнительных команд для идентификации или конфигурирования адаптера.
interface name [Config Command]
Использовать заданное имя драйвера интерфейса для подключения к target.
interface_list [Command]
Показать список драйверов адаптера отладки, которые встроены в запущенную копию OpenOCD.
interface transports transport_name+ [Command]
Указывает транспорты, поддерживаемые этим адаптером отладки. В драйвере адаптера такие данные уже заложены; используйте это только тогда, когда внешняя конфигурация (такая как перестановка перемычек) может изменить поддерживаемую аппаратуру.
adapter_name [Command]
Возвращает имя используемого драйвера адаптера отладки.
8.2. Драйверы интерфейса (Interface Drivers)
Каждый из перечисленных здесь драйверов интерфейса должен быть явно разрешен при конфигурировании OpenOCD - чтобы адаптер был доступен во время выполнения.
amt_jtagaccel [Interface Driver]
Amontec Chameleon в конфигурации как JTAG Accelerator, подключенный к параллельному порту (LPT) в режиме EPP. Это определяет некоторые команды, специфичные для драйвера:
parport_port number [Config Command]
Указывает адрес порта ввода/вывода (по умолчанию 0x378 для LPT1) или номер устройства /dev/parport.
rtck [enable|disable] [Config Command]
Отображает статус опции RTCK. Такая опция предварительно устанавливается по выбору.
arm-jtag-ew [Interface Driver]
USB адаптер Olimex ARM-JTAG-EW, который имеет одну специфичную для него команду:
armjtagew_info [Command]
Выводит лог некоторой информации о статусе.
at91rm9200 [Interface Driver]
Поддерживает bitbang JTAG из локальной системы, предполагается что система Atmel AT91rm9200 и используется специфический набор GPIO.
dummy [Interface Driver]
Чисто программный драйвер для отладки.
ep93xx [Interface Driver]
Одноплатный компьютер, основанный на Cirrus Logic EP93xx, применяется bitbang (в разработке).
ft2232 [Interface Driver]
Адаптеры, основанные на чипах FTDI FT2232 (USB) и работающих через библиотеки уровня пользователя (userspace libraries, термин относится к специфике работы программного обеспечения в операционной системе). Имейте в виду, что этот драйвер имеет недостатки, и рекомендуется в качестве замены использовать драйвер ftdi.
Эти интерфейсы имеют несколько команд, используемых для конфигурирования драйвера перед инициализацией цепочки JTAG (JTAG scan chain):
ft2232_device_desc description [Config Command]
Предоставляет описание устройства USB (строку iProduct) устройства FTDI FT2232. Если не указано, то используется значение по умолчанию для FTDI. Эта установка допустима только если компиляция была сделана с поддержкой FTD2XX.
ft2232_serial serial-number [Config Command]
Указывает серийный номер используемого устройства FTDI FT2232, в том случае, когда вендор предоставляет уникальные ID, и к хосту подключено больше одного устройства FT2232. Если не указано, серийные номера не учитываются. Имейте в виду, что серийные номера USB могут быть произвольными строками Unicode, и нет ограничений, что они будут содержать только цифровые символы.
ft2232_layout name [Config Command]
Каждое устройство FT2232 вендора может иметь разные сигналы GPIO для управления разрешающими выходами, сигналами сброса и светодиодами (LED). В настоящий момент есть следующие допустимы имена разводок сигналов:
- axm0432_jtag Axiom AXM-0432
- comstick Hitex STR9 comstick
- cortino Hitex Cortino JTAG interface
- evb_lm3s811 TI/Luminary Micro EVB_LM3S811 в качестве интерфейса JTAG, либо для локального Cortex-M3 (только SRST), либо в сквозном режиме (passthrough mode, в этом случае нет ни SRST, ни TRST). Эта разводка сигналов не может поддерживать механизм трассировки SWO, и должна использоваться только для старых плат (до rev C).
- luminary_icdi Эта разводка должна использоваться с большинством плат TI/Luminary, исключая отладочные платы Rev C LM3S811 и базовые платы ICDIs, чтобы отлаживать либо локальный Cortex-M3, либо работать в сквозном режиме (passthrough mode) для отладки других target-ов. Может поддерживать механизм трассировки SWO.
- flyswatter Tin Can Tools Flyswatter
- icebear адаптер ICEbear JTAG из Секции 5
- jtagkey Amontec JTAGkey и JTAGkey-Tiny (и все совместимые с ними)
- jtagkey2 Amontec JTAGkey2 (и все совместимые с ними)
- m5960 American Microsystems M5960
- olimex-jtag Olimex ARM-USB-OCD и ARM-USB-Tiny
- oocdlink OOCDLink
- redbee-econotag адаптер, интегрированный в плату разработчика Redbee development board.
- redbee-usb адаптер, интегрированный в плату разработчика Redbee USB-stick development board.
- sheevaplug Marvell Sheevaplug development kit
- signalyzer Xverve Signalyzer
- stm32stick Hitex STM32 Performance Stick
- turtelizer2 egnite Software turtelizer2
- usbjtag разводка сигналов "USBJTAG-1", описанная в дипломных тезисах OpenOCD
ft2232_vid_pid [vid pid]+ [Config Command]
Параметры vendor ID и product ID устройства FTDI FT2232. Если не указано, то будут использоваться значения по умолчанию для устройств FTDI. В настоящий момент может быть предоставлено до 8 пар [vid, pid], например:
ft2232_vid_pid 0x0403 0xcff8 0x15ba 0x0003
ft2232_latency ms [Config Command]
На некоторых системах, использующих интерфейсы JTAG на основе FT2232, вызовы функции FT_Read в ft2232_read() заканчиваются неудачей для возврата ожидаемого количества байт. Это может происходить из-за задержек в обмене данными по шине USB, и этот баг оказался сложным для воспроизведения и отладки. Установка таймера задержки (latency timer) FT2232 на увеличенное значение повышает время задержек для коротких пакетов USB, но также уменьшает риск получения таймаутов перед приемом ожидаемого количества байт. Значение по умолчанию для OpenOCD равно 2, и в некоторых системах значение 10 будет полезным.
ft2232_channel channel [Config Command]
Применяется для выбора используемого канала чипа ft2232 (от 1 до 4. Примечание переводчика: на самом деле у микросхем FT2232D и FT2232H только 2 канала. 4 канала есть только у микросхем FT4232, так что наверное диапазон значений от 1 до 4 выбран для совместимости с ними). Значение по умолчанию 1. Например, файл interface config для Turtelizer JTAG Adapter будет выглядеть примерно так:
interface ft2232
ft2232_device_desc "Turtelizer JTAG/RS232 Adapter"
ft2232_layout turtelizer2
ft2232_vid_pid 0x0403 0xbdc8
ftdi [Interface Driver]
Этот драйвер для адаптеров, использующих режим MPSSE (Multi-Protocol Synchronous Serial Engine), встроенный во многие чипы FTDI, такие как FT2232, FT4232 и FT232H. Он полностью переписан из-за большого количества проблем с драйвером интерфейса ft2232.
Драйвер использует libusb-1.0 в асинхронном режиме для обмена данными с устройством FTDI, пропуская промежуточные библиотеки наподобие libftdi из D2XX. В плане производительности это работает значительно быстрее, чем драйвер ft2232, иногда в несколько раз.
Главное улучшение в этом драйвере - поддержка новых адаптеров на основе микросхем FTDI полностью выполняется через файлы конфигурации, без необходимости применять патч и пересобирать OpenOCD.
Драйвер использует сигнальную абстракцию, чтобы разрешить конфигурационным файлам Tcl задать выходы для одного или нескольких FTDI GPIO. Эти выходы затем могут управляться командами ftdi_set_signal. Специальные имена сигналов зарезервированы для nTRST, nSRST и LED (который мерцает), так что они, если заданы, будут использоваться для своего общепринятого предназначения.
В зависимости от типа буфера, подключенного к FTDI GPIO (имеется в виду аппаратный внешний буфер сигналов логики), выходы управляются раздельно. Для поддержки сигналов с тремя состояниями наподобие nSRST, для каждого сигнала можно указать как data, так и output-enable GPIO. Поддерживаются следующие конфигурации выходного буфера:
- Push-pull с одним выходом FTDI как провод прямого или инверсного сигнала данных.
- Открытый сток с одним выходом FTDI в качестве прямого или инверсного сигнала разрешения.
- Сигнал с тремя состояниями, где один выход FTDI используется как прямой или инверсный сигнал данных, и другой выход FTDI используется как прямой или инверсный сигнал разрешения.
- Без буфера, используя FTDI GPIO как выход с тремя состояниями напрямую, путем переключения направления и данных, когда это нужно.
Эти интерфейсы имеют несколько команд, используемых для конфигурирования драйвера перед инициализации цепочки JTAG (JTAG scan chain):
ftdi_vid_pid [vid pid]+ [Config Command]
Vendor ID и product ID для адаптера. Если не указано, то используются идентификаторы FTDI по умолчанию. В настоящий момент можно задать до 8 пар [vid, pid], например так:
ftdi_vid_pid 0x0403 0xcff8 0x15ba 0x0003
ftdi_device_desc description [Config Command]
Предоставляет описание устройства USB (description содержит строку iProduct) адаптера. Если не указано, то описание игнорируется при выборе устройства.
ftdi_serial serial-number [Config Command]
Указывает серийный номер используемого адаптера, в том случае, когда вендор предоставляет уникальные ID, и к хосту подключено больше одного устройства FT2232. Если не указано, серийные номера не учитываются. Имейте в виду, что серийные номера USB могут быть произвольными строками Unicode, и нет ограничений, что они будут содержать только цифровые символы.
ftdi_channel channel [Config Command]
Выбирает канал устройства FTDI для использования операций MPSSE. Большинство адаптеров использует значение по умолчанию, канал 0, но есть и исключения.
ftdi_layout_init data direction [Config Command]
Указывает начальные значения регистров данных и направления FTDI GPIO. Каждое значение является 16-битным числом, соответствующее лог. 1 и лог. 0 битов регистров FTDI GPIO. Значения должны быть выбраны на основании принципиальной схемы адаптера, чтобы все сигналы были установлены в безопасные уровни для минимального воздействия на target system. Позволяет избежать плавающих входов, конфликтов выходов и изначально установленных сигналов сброса.
ftdi_layout_signal name [-data|-ndata data_mask] [-oe|-noe oe_mask] [Config Command]
Создает сигнал с указанным именем, управляемый одной или несколькими ножками FTDI GPIO через некий диапазон соединения с аппаратным буфером. Маски - это битовые маски регистра FTDI GPIO, чтобы указать драйверу соединение и тип выходного буфера, который передает соответствующий сигнал. Значение data_mask является битовой маской для ножек, подключенных ко входу выходного аппаратного буфера. -ndata используется с инвертирующими входами данных, и -data с неинвертирующими входами. Опция -oe (или -noe) говорит, какой подключен вход выходного буфера, output-enable (или not-output-enable).
Не нужно указывать оба параметра data_mask и oe_mask. Например, простой драйвер в виде транзистора с открытым коллектором должен быть указан только с -oe. В случае, если сигнал устанавливается только для выдачи лог. 0 или Hi-Z и драйвер будет жаловаться, если сигнал установлен для передачи лог. 1. Который означает если это сигнал сброса, reset_config должен быть указан как srst_open_drain, а не srst_push_pull.
Специальный случай, когда -data и -oe установлены с одинаковой битовой маской. Тогда подразумевается, что вывод FTDI подключен напрямую к target без аппаратного буфера. Так что вывод FTDI переключается между режимов выхода и входа, если это необходимо для предоставления всех характеристик состояний сигнала лог. 0, лог. 1 и Hi-Z. Во всех других случаях выводы, указанные в определении сигнала, всегда управляются от FTDI.
ftdi_set_signal name 0|1|z [Command]
Устанавливает ранее заданные сигналы на указанный уровень.
- 0, выставляется лог. 0
- 1, выставляется лог. 0
- z, выставляется Hi-Z
Для примеров определения адаптера смотрите конфигурационные файлы в директории interface/ftdi.
remote_bitbang [Interface Driver]
Управление JTAG от дальнего процесса. Это делается через соединение сокетом UNIX или сокетом TCP, где отдаленный процесс посылает закодированные в ASCII bitbang-запросы, которые обрабатываются и передаются в JTAG (вместо непосредственного управления сигналами JTAG).
Драйвер remote_bitbang полезен для отладки firmware, запущенного на симулируемом процессоре.
remote_bitbang_port number [Config Command]
Указывает номер порта TCP к которому будет подключаться дальний процесс, либо 0 для использования сокетов UNIX вместо TCP.
remote_bitbang_host hostname [Config Command]
Указывает имя хоста, к которому будет подключаться дальний процесс с использованием TCP, или имя используемого сокета UNIX, если remote_bitbang_port равен 0.
Например, чтобы удаленно подключиться через TCP к хосту foobar, у Вас должно быть что-то типа такого:
interface remote_bitbang
remote_bitbang_port 3335
remote_bitbang_host foobar
Для подключения к другому процессу, запущенному локально через сокеты UNIX, сокет называется mysocket:
interface remote_bitbang
remote_bitbang_port 0
remote_bitbang_host mysocket
usb_blaster [Interface Driver]
Адаптер, совместимый с USB JTAG/USB-Blaster, работающий через одну из библиотек области пользователя для чипов FTDI. Эти интерфейсы имеют несколько команд, используемых для конфигурирования драйвера перед инициализацией цепочки JTAG (JTAG scan chain):
usb_blaster_device_desc description [Config Command]
Предоставляет описание устройства USB (строка iProduct) на микросхеме FTDI FT245. Если не указано, то используется значение по умолчанию FTDI. Эта установка работает только тогда, когда OpenOCD скомпилирована с поддержкой FTD2XX.
usb_blaster_vid_pid vid pid [Config Command]
Значения vendor ID и product ID для микросхемы FTDI FT245. Если не указаны, то будут использоваться значения по умолчанию. Сейчас может быть указана только одна пара vid pid, например для Altera USB-Blaster (по умолчанию):
usb_blaster_vid_pid 0x09FB 0x6001
Следующие VID/PID используются для Kolja Waschk USB JTAG:
usb_blaster_vid_pid 0x16C0 0x06AD
usb_blaster (pin6|pin8) (0|1) [Command]
Устанавливает состояние неиспользуемых выводов GPIO USB-Blaster-ах (вывод 6 и 8 на коннекторе JTAG мама). Эти выводы можно использовать как SRST и/или TRST с соответствующим подключением к целевой плате.
Например, для использования вывода 6 в качестве SRST (как на AVR board):
$_TARGETNAME configure -event reset-assert
"usb_blaster pin6 1; wait 1; usb_blaster pin6 0"
gw16012 [Interface Driver]
JTAG-программатор Gateworks GW16012. У него есть одна специфичная для его драйвера команда:
parport_port [port_number] [Config Command]
Отображает либо адрес порта I/O (по умолчанию 0x378 для LPT1) или номер устройства /dev/parport. Если параметр указан, первое переключение использует этот порт. Это установка используется на запись, и только один раз.
jlink [Interface Driver]
Семейство USB-адаптеров Segger J-Link. В настоящий момент поддерживает только транспорт JTAG.
Указание, касающееся совместимости: у компании Segger имеется много релизов версий firmware для многих представленных аппаратных версий. OpenOCD была широко протестирована для работы со всеми их вариантами, но сообщалось, что некоторые комбинации несовместимы. В качестве основной рекомендации - желательно использовать последнюю версию firmware, доступную для каждой версии hardware. Однако текущая версия V8 является улучшаемой, и версии Segger firmware, выпущенные после релиза OpenOCD, могут быть несовместимыми. В таком случае рекомендуется откатить firmware отладчика к последней известной функциональной версии. Для OpenOCD 0.5.0 это версия от "Feb 8 2012 14:30:39", упакованная 4.42c. Для OpenOCD 0.6.0 последняя известная версия от "May 3 2012 18:36:22" упакованная 4.46f.
jlink caps [Command]
Отображает возможности firmware устройства.
jlink info [Command]
Отображает разную информацию об устройстве, типа версии аппаратуры (hardware version), версии firmware, текущее состояние шины.
jlink hw_jtag [2|3] [Command]
Устанавливает текущую используемую версию протокола JTAG. Без аргумента показывает актуальную версию протокола JTAG.
jlink config [Command]
Отображает конфигурацию J-Link.
jlink config kickstart [val] [Command]
Устанавливает Kickstart power вывода 19 JTAG (управление питанием?). Без аргумента показывает конфигурацию Kickstart.
jlink config mac_address [ff:ff:ff:ff:ff:ff] [Command]
Устанавливает MAC-адрес адаптера J-Link Pro. Без аргумента показывает MAC-адрес.
jlink config ip [A.B.C.D(/E|F.G.H.I)] [Command]
Устанавливает конфигурацию IP адаптера J-Link Pro, где A.B.C.D адрес IP, E количество битов маски подсети, и F.G.H.I маска подсети в явно указанном виде. Без аргумента показывает конфигурацию IP.
jlink config usb_address [0x00 .. 0x03 или 0xff] [Command]
Устанавливает адрес USB; это также поменяет product id. Без аргумента покажет адрес USB.
jlink config reset [Command]
Сброс текущей конфигурации.
jlink config save [Command]
Сохранение текущей конфигурации во внутреннее постоянное хранилище.
jlink pid val [Config]
Устанавливает для интерфейса USB PID. Как команда конфигурации, она может использоваться только перед 'init'.
parport [Interface Driver]
Поддерживает bitbang-кабели для параллельного порта PC (LPT): Wiggler, PLD download cable, и другие. Эти интерфейсы имеют несколько команд, используемых для конфигурирования драйвера перед инициализацией JTAG scan chain:
parport_cable name [Config Command]
Устанавливает разводку сигналов параллельного порта для конкретного кабеля, через который подключается target. Эта установка только для записи, и применяется только один раз. Сейчас допустимы следующие значения имени:
- altium Altium Universal JTAG cable.
- arm-jtag то же самое, что и оригинальный wiggler, за исключением того, что соединения SRST и TRST зарезервированы и также инвертирован TRST.
- chameleon адаптер Amontec Chameleon’s CPLD, когда работает в конфигурационном режиме. Используется только для программирования самого Chameleon, а не подключенной target.
- dlc5 Xilinx Parallel cable III.
- flashlink ST Parallel cable.
- lattice Lattice ispDOWNLOAD Cable
- old_amt_wiggler конфигурация Wiggler, которая поставляется с некоторыми версиями Amontec’s Chameleon Programmer. Новые версии, доступные с сайта, используют оригинальную разводку Wiggler ('wiggler')
- triton адаптер параллельного порта, который можно найти на "Karo Triton 1 Development Board". Эта разводка также используется в разработке HollyGates (см. http://www.lartmaker.nl/projects/jtag/).
- wiggler оригинальная разводка Wiggler, также поддерживаемая несколькими клонами, такими как Olimex ARM-JTAG
- wiggler2 то же самое, что и оригинальный wiggler, за исключением того, что LED соответствует D5.
- wiggler_ntrst_inverted то же, что и оригинальный wiggler, за исключением того, что TRST проинвертирован.
parport_port [port_number] [Config Command]
Отображает либо адрес порта I/O (по умолчанию 0x378 для LPT1) или номер устройства /dev/parport. Если параметр предоставлен, то сначала происходит переключение на использование этого порта. Это установка только для записи, и делается только один раз.
Когда для доступа к параллельному порту используется PPDEV, используйте номер параллельного порта: parport_port 0 (по умолчанию). Если укажете parport_port 0x378, то можете столкнуться с проблемой.
parport_toggling_time [nanoseconds] [Command]
Отображает, сколько наносекунд нужно аппаратуре, чтобы переключить TCK; драйвер parport использует это значение для того, чтобы соответствовать конфигурации adapter_khz. Когда задан необязательный параметр nanoseconds, то эта установка изменится перед отображением текущего значения.
Значение по умолчанию должно работать обоснованно хорошо на любой аппаратуре PC. Однако, Вы можете захотеть откалибровать Вашу специфичную аппаратуру.
Совет: чтобы измерить время переключение с помощью логического анализатора или цифрового осциллографа, следуйте такой процедуре:
> parport_toggling_time 1000
> adapter_khz 500
Эта установка задаст максимальную тактовую частоту JTAG на аппаратуре, но актуальная частота будет варьироваться и отличаться от запрошенных 500 кГц. Теперь измерьте время между ближайшими изменениями уровня TCK. Вы можете использовать 1000 или близкое значение для генерирования большого набора выборок. Обновите установку для того, чтобы она соответствовала Вашему измерению:
> parport_toggling_time < measured nanoseconds >
Теперь тактовая частота будет лучше соответствовать командам adapter_khz rate, которые выдают скрипты OpenOCD scripts и обработчики событий.
Вы можете сделать нечто такое же, используя многие цифровые мультиметры, но имейте в виду, что Вам возможно над запустить формирование тактов на несколько секунд, перед тем как оцените скорость тактов. Подстройте время переключения вверх или вниз, пока измеренная частота тактов будет хорошо соответствовать указанной Вами скорости adapter_khz; будьте консервативны.
parport_write_on_exit (on|off) [Config Command]
Это сконфигурирует параллельный драйвер записывать при выходе из OpenOCD в параллельный интерфейс известное специфичное для кабеля значение.
Например, файл interface config для классического кабеля Wiggler на LPT2 может выглядеть примерно так:
interface parport
parport_port 0x278
parport_cable wiggler
presto [Interface Driver]
ASIX PRESTO USB JTAG programmer.
presto_serial serial_string [Config Command]
Конфигурирует серийный номер USB, используемый в устройстве Presto.
rlink [Interface Driver]
Raisonance RLink USB adapter.
usbprog [Interface Driver]
usbprog, свободный программируемый адаптер USB.
vsllink [Interface Driver]
vsllink, часть Versaloon, который является программатором versatile USB programmer.
Внимание: этот вариант драйвера интерфейса задает несколько специфичных для драйвера команд, которые здесь пока не задокументированы.
hla [Interface Driver]
Этот драйвер поддерживает несколько High Level Adapter (адаптер высокого уровня). Этот тип адаптера не предоставляет низкоуровневый API, который OpenOCD обычно использует для доступа к target.
В настоящий момент поддерживаемые адаптеры включают ST STLINK и TI ICDI.
hla_device_desc description [Config Command]
В настоящее время не поддерживается.
hla_serial serial [Config Command]
В настоящее время не поддерживается.
hla_layout (stlink|icdi) [Config Command]
Задает используемую разводку сигналов в адаптере.
hla_vid_pid vid pid [Config Command]
Значения vendor ID и product ID устройства.
stlink_api api_level [Config Command]
Вручную устанавливает используемое stlink api, допустимые опции 1 или 2. (касается только STLINK).
opendous [Interface Driver]
opendous-jtag, свободный программируемый адаптер USB.
ulink [Interface Driver]
Это отладчик Keil ULINK v1 JTAG.
ZY1000 [Interface Driver]
Это отладчик Zylin ZY1000 JTAG.
Внимание: этот вариант драйвера интерфейса задает некоторые специфичные для драйвера команды, которые в настоящее время здесь не задокументированы.
power [on|off] [Command]
Переключает ключ питания target в состояние включено (on) или выключено (off). Без аргументов: выводит статус.
8.3. Конфигурация транспорта (Transport Configuration)
Как было замечено ранее, в зависимости от используемой Вами версии OpenOCD и в зависимости от адаптера отладки могут быть доступны разные транспорты для обмена данными с debug target-ами (или может быть для программирования памяти flash).
transport list [Command]
Отображает имена поддерживаемых транспортов в этой версии OpenOCD.
transport select transport_name [Command]
Выбирает, какой из поддерживаемых транспортов будет использоваться в этой сессии OpenOCD. Транспорт должен поддерживаться аппаратурой адаптера отладки и версией OpenOCD (включая драйвером адаптера). Без аргументов возвращает имя выбранного транспорта для сессии.
8.3.1. JTAG Transport
JTAG является оригинальным транспортом, изначально поддерживаемым OpenOCD и большинство команд OpenOCD поддерживает его. Транспорты JTAG представляют цепочку из одного или большего количества Test Access Point (TAP), каждая из которых должна быть явно задекларирована. JTAG поддерживает и отладку, и тестирование boundary scan. Программирование flash поддерживается благодаря протоколу отладки.
8.3.2. SWD Transport
SWD (Serial Wire Debug) является транспортом, специфичным для ARM, который представляет одну Debug Access Point (DAP), которая должна быть явно задекларирована. SWD использует меньше сигнальных линий, чем JTAG. SWD ориентирован на отладку, он не поддерживает тестирование boundary scan. Программирование flash поддерживается благодаря протоколу отладки. Некоторые процессоры поддерживают одновременно и JTAG, и SWD.
swd newdap ... [Command]
Декларирует одну DAP, используемую транспортом SWD. Параметры в настоящий момент те же самые, что и у "jtag newtap", но возможно это изменится.
swd wcr trn prescale [Command]
Обновляет TRN (turnaround delay, оборотная задержка) и поля прескалинга (prescaling.fields) регистра Wire Control Register (WCR). Без параметров отображает текущую установку.
8.3.3. SPI Transport
Serial Peripheral Interface (SPI) является транспортом общего назначения, который использует 4 сигнала. Некоторые процессоры используют его как средство программирования flash.
8.4. Скорость JTAG (JTAG Speed)
Настройка тактовой частоты JTAG является частью настройки системы. Это не относится к настройке интерфейса (interface setup) поскольку любой интерфейс знает только некоторые ограничения на скорость тактов JTAG. Иногда скорость JTAG изменяется во время процесса инициализации target: (1) при сбросе низкая скорость, (2) программирование тактов CPU, (3) переключение на высокую скорость. Оба варианта тактовых частот "медленно" и "быстро" являются функциями используемых генераторов, чипа, дизайна платы, и иногда от активности программного обеспечения, управляющего питанием (power management software).
Скорость, используемая при сбросе, и проверка цепочки JTAG, которая следует за сбросом, может быть подстроена с использованием обработчика события reset-start target (event handler). Обработчик может быть реконфигурирован на повышенную скорость обработчиком reset-init target event handler после того, как он перепрограммирует тактовые частоты CPU, или вручную (или как-нибудь по-другому, например с помощью бутлоадера, настраивающего эти такты). См. раздел 11.5. События цели (Target Events). Когда изначальная низкая скорость JTAG является характеристикой чипа, возможно по причине требуемой скорости генератора, такой обработчик предоставляется в файле target config. Когда такая скорость зависит от аппаратуры платы (board-specific), как например какая скорость генератора используется, то вместо этого настройка принадлежит файлу board config. В обоих случаях безопаснее всего также установить начальную скорость тактов JTAG на ту же низкую скорость, так что OpenOCD не будет стартовать с использованием тактовой частоты выше, чем может поддержать цепочка JTAG.
jtag_rclk 3000
$_TARGET.cpu configure -event reset-start { jtag_rclk 3000 }
Если Ваша система поддерживает адаптивное тактирование (RTCK), сконфигурируйте JTAG для использование этой возможности как самое удобное решение. Однако могут быть задержки для синхронизации тактов; так что это решение не относится к самым быстрым.
Внимание: при написании скриптов нужно рассмотреть возможность использования jtag_rclk вместо adapter_khz, но только для (ARM) ядер и плат, которые поддерживают адаптивное тактирование.
adapter_khz max_speed_kHz [Command]
Ненулевое значение скорости в килогерцах. К примеру 3000 соответствует частоте 3 МГц. Интерфейсы JTAG обычно поддерживают ограниченное количество скоростей. Актуально используемая скорость не должна быть выше, чем указанная.
Даташиты на чип обычно указывают предельную скорость тактов JTAG. Реальная скорость часто является функцией от тактовой частоты ядра CPU, и обычно меньше, чем пиковая скорость. Например, большинство ядер ARM принимают самое большее одну шестую тактовой частоты CPU.
Скорость 0 (кГц) выбирает метод RTCK (адаптивное тактирование). См. RTCK в разделе [23. FAQ]. Если Ваша система использует RTCK, то Вам не надо изменять тактирование JTAG после настройки. Не все интерфейсы, платы или target-ы поддерживают "rtck". Если устройство интерфейса не поддерживает это, то будет возвращена ошибка при попытке использовать RTCK.
jtag_rclk fallback_speed_kHz [Function]
Это процедура Tcl (определенная в startup.tcl), которая пытается разрешить RTCK/RCLK. Если она возвращается с ошибкой (возможно интерфейс, плата или target не поддерживает это), то происходит откат к указанной частоте.
# Возврат обратно к частоте 3 МГц, если RTCK не поддерживается
jtag_rclk 3000
[9. Конфигурация сброса (Reset Configuration)]
Каждая конфигурация системы может требовать для себя различной конфигурации сброса. Это может несколько сконфузить. Сбросы также взаимодействуют с обработчиками события reset-init event handlers, которые делают такие вещи, как установка тактовых частот, настройка DRAM, и задание тактовых частот JTAG, см. раздел 8.4. Скорость JTAG (JTAG Speed). Они могут также взаимодействовать с маршрутизаторами JTAG. Пожалуйста смотрите различные файлы board для примера.
Внимание интеграторам и специалистам поддержки: конфигурация сброса затрагивает сразу несколько аспектов. Обычно файл board config должен задать конфигурацию сброса, и подразумевается что адаптер JTAG поддерживает все, что подключено к нему через коннектор JTAG платы.
Однако файл target config должен также уделить внимание тому, как вендор чипа организовал его внутреннее устройство. Это верно для большинства (или всех) плат, которые используют этот чип. И когда адаптер JTAG не поддерживает что-то, файл конфигурации пользователя (user configuration) должен отменить части конфигурации сброса, которые предоставлены другими файлами конфигурации.
9.1. Типы сброса
Есть несколько вариантов сброса через JTAG, но они могут работать не все с имеющейся платой и имеющимся адаптером отладки. Это частая причина того, что неправильная конфигурация сброса может привести к ошибкам.
• System Reset, системный сброс. Аппаратный сигнал SRST сбрасывает все чипы, подключенные к адаптеру JTAG - процессоры, чипы управления питанием (power management chips) и контроллеры I/O. Обычно сбросы, которые срабатывают по этому сигналу, работают так же, как и от нажатия кнопки RESET.
• JTAG TAP Reset. Аппаратный сигнал TRST сбрасывает только контроллеры TAP, подключенные к адаптеру JTAG. Такие сбросы не должны быть видимы для остальной части системы; сброс контроллера устройства просто переводит контроллер в известное заранее состояние.
• Emulation Reset. Многие устройства могут быть сброшены через команды JTAG. Эти сбросы часто отличаются от system reset, либо явно (это говори регистр "reset reason", "причина сброса"), либо неявно (сбрасываются не все части чипа).
• Other Resets, другие виды сброса. Устройства типа system-on-chip (система на чипе) часто поддерживают несколько других типов сброса. Вам может потребоваться разобраться с остановкой таймера watchdog при отладке, чтобы предотвратить watchdog reset. Могут быть сбросы, индивидуальные для модулей чипа.
В лучшем случае OpenOCD может удержать SRST, затем сбросить TAP-ы сигналом TRST и отправить команды через JTAG, чтобы остановить CPU на векторе сброса перед выполнением первой инструкции. Затем когда OpenOCD отпустит сигнал SRST, система будет остановлена под управлением отладчика перед выполнением любого кода. Это поведение, требуемое для поддержки останова по сбросу (reset halt) и команд reset init; после reset init скрипт, специфичный для платы может делать что-нибудь наподобие настройки DRAM. См. команду reset в разделе 16.2. Обработка состояний target (Target State handling).
9.2. Проблемы, связанные с SRST и TRST
Поскольку SRST и TRST являются аппаратными сигналами, то они могут иметь различные зависящие от системы ограничения. Вот некоторые общие проблемы, связанные с этим:
• Signal not available (сигнал недоступен). Некоторые платы не разводят сигналы SRST или TRST на коннектор JTAG. Некоторые адаптеры JTAG не поддерживают такие сигналы, даже если они разведены. Используйте опции reset_config signals, когда надо указать, что эти сигналы не подключены. Когда нет сигнала SRST, то Ваш код может не смочь воспользоваться контроллерами, полностью сброшенными во время запуска кода. Отсутствие TRST не является проблемой, поскольку сбросы уровня JTAG могут быть запущены сигналингом TMS.
• Signals shorted (сигналы замкнуты). Иногда чип, плата или адаптер соединяют друг с другом SRST и TRST, вместо того чтобы разделить их. Используйте опции reset_config combination, чтобы указать, что эти сигналы не являются нормально независимыми.
• Timing (тайминг, длительности сигналов). Узлы сброса типа схемы задержки на резисторе / конденсаторе, супервизор сброса, или встроенные в чип возможности могут изменять эффект от выдаваемого адаптером JTAG сброса. Сброс может продолжаться еще некоторое время, когда адаптер уже прекратил выдавать сигнал сброса. Например, есть требование чипа или платы, чтобы все импульсы сброса были как минимум заданной длительности; аппаратные кнопки сброса обычно имеют аппаратное подавление дребезга. Используйте команды adapter_nsrst_delay и jtag_ntrst_delay, чтобы указать, когда нужна дополнительная задержка после выдачи сброса.
• Drive type (способ выдачи сигнала сброса). Сигналы сброса часто имеют pullup резистор, что позволяет интерфейсу JTAG использовать для управления открытый сток. Но это необязательное требование, и некоторые адаптеры могут нуждаться в использовании выходных драйверов типа push/pull (двухтактный выход). Также при слабых pullup (когда резистор имеет высокое сопротивление) может быть полезно управлять сигналами по обоим логическим уровням (push/pull) чтобы минимизировать время нарастания импульса сброса. Используйте reset_config с параметрами trst_type и srst_type, чтобы сказать, как управляются сигналы сброса.
• Special initialization (специальная инициализация). Target-ы иногда нуждаются в специальных последовательностях инициализации JTAG, чтобы решить проблемы специфики чипа (эти проблемы не ограничены указаниями errata). Например, может потребоваться выдать определенные команды JTAG, в то время как система в целом находится в состоянии сброса (активен SRST), но цепочка JTAG работоспособна (TRST в неактивном состоянии). Многие системы требуют комбинированного управления SRST и TRST для более жесткого сброса, чем просто от одного SRST. Такая частная обработка reset обсуждается далее в этом разделе.
Со сбросом могут быть также и другие проблемы. Некоторые устройства не полностью соответствуют спецификациям JTAG. Встречаются также тривиальные специфичные для системы отличия, такие как использование для SRST и TRST незначительно отличающихся других имен. Здесь также вендоры, которые распространяют ключевую документацию по JTAG только для разработчиков, подписавшихся на неразглашение данных (Non-Disclosure Agreement, NDA).
Иногда бывают специфические для чипа расширения, наподобие требования использовать (обычно необязательный) сигнал TRST (что устраняет возможность использования адаптеров JTAG, не обеспечивающих выход TRST), или необходимость выполнить дополнительные шаги, чтобы полностью выполнить сброс TAP.
Если коротко - обработка SRST и в особенности TRST может быть очень привередливой, требующей учета специфичных ограничений как архитектуры, так и платы.
9.3. Команды для поддержки сигналов сброса
adapter_nsrst_assert_width milliseconds [Command]
Минимальная величина времени (в миллисекунда), которую OpenOCD должна ждать после выдачи nSRST (сброс системы, активный лог. 0), перед тем как убрать этот сигнал.
adapter_nsrst_delay milliseconds [Command]
Как долго (в миллисекундах) OpenOCD должна ждать после того, как уберет сигнал nSRST (сброс системы, активный лог. 0), перед началом новых операций с JTAG. Когда плата была сброшена кнопкой, подключенной к SRST, то на этом сигнале наверняка имеются аппаратный дребезг, учесть который Вы можете с помощью этого параметра.
jtag_ntrst_assert_width milliseconds [Command]
Минимальная величина времени (в миллисекунда), которую OpenOCD должна ждать после выдачи nTRST (сброс JTAG TAP, активный лог. 0), перед тем как убрать этот сигнал.
jtag_ntrst_delay milliseconds [Command]
Как долго (в миллисекундах) OpenOCD должна ждать после того, как уберет сигнал nTRST (сброс JTAG TAP, активный лог. 0) перед началом новых операций с JTAG.
reset_config mode_flag ... [Command]
Эта команда отображает или модифицирует конфигурацию сброса Вашей комбинации JTAG board и target в скриптах target config.
В этой секции ранее была приведена информация, описывающая проблемы сброса (см. раздел 9.2. Проблемы, связанные с SRST и TRST). Правило применения команд, настраивающих сброс, состоит в том, чтобы задавать их только в файлах board config, если описываются проблемы наподобие отсутствия подключения на плате сигнала TRST; или команда должна быть в файлах конфигурации пользователя, если адресуются ограничения, происходящие из частной комбинации интерфейса и платы. (Маловероятный пример использовал бы адаптер только с TRST с платой, на которой разведен только SRST.)
Опции mode_flag могут быть указаны в любом порядке, но только один раз для каждого типа – signals (сигналы), combination (комбинация), gates (логические элементы), trst_type, srst_type и connect_type. Если Вы не предоставили нового значения для указанной величины, её предыдущее значение (возможно значение по умолчанию) останется неизменным. Например, это означает, что Вам не надо говорить что-то еще о TRST, просто декларируйте, что если адаптер JTAG должен управлять сигналом SRST, он должен явно поддерживать переключение в высокий уровень (srst_push_pull).
• signals может указать, какие сигналы сброса подключены. Например, если интерфейс JTAG предоставляет SRST, но плата не подключает правильно этот сигнал, то OpenOCD не сможет его использовать. Возможные значения none (по умолчанию), trst_only, srst_only и trst_and_srst.
• combination необязательное значение, указывающее на неисправные реализации сигнала reset. Поведение по умолчанию separate, если не предоставлено отдельной опции, что показывает нормальную работу. Опция srst_pulls_trst указывает, что сброс логики тестирования объединен со сбросом системы (например NXP LPC2000, "ошибочная" разводка платы), trst_pulls_srst говорит, что сброс системы работает вместе со сбросом логики тестирования (бывает только гипотетически, такой баг в аппаратуре пока не встречался, но если встретится, то можно его обойти). combined подразумевает сразу и srst_pulls_trst, и trst_pulls_srst.
• Токены gates управляют флагами, которые описывают некоторые случаи, когда JTAG может быть недоступен во время сброса. Опция srst_gates_jtag (по умолчанию) показывает, что выставление SRST запирает такты JTAG. Это означает, что не может быть обмена через JTAG, пока выставлен сигнал SRST. Конверсия этого флага srst_nogate, это показывает, что команды JTAG можно безопасно передавать, когда SRST активен.
• Токены connect_type управляют флагами, которые показывают отдельные случаи, когда SRST выставляется при подключении к target. Для использования этой опции нужно применить srst_nogate. Опция connect_deassert_srst (по умолчанию) показывает, что SRST не будет выставлен при подключении к target. Конверсия этого connect_assert_srst, показывающий, что SRST будет выставлен перед любым подключении к target. Только некоторые target-ы поддерживают эту возможность, например STM32 и STR9. Эта возможность полезна, если Вы не можете соединиться с target из-за некорректной конфигурации байта опций или из-за ошибки в программе.
Необязательные параметры trst_type и srst_type, если они указаны, позволяют указать режим драйвера для каждого из сигналов сброса. Эти значения влияют только на интерфейсы JTAG с поддержкой разных режимов драйвера, наподобие Amontec JTAGkey и JTAG Accelerator. Также они будут обязательно проигнорированы, если соответствующий сигнал (TRST или SRST) не подключен.
• Возможны режимы драйвера trst_type для сигнала сброса тестирования (TRST) - trst_open_drain и по умолчанию trst_push_pull. Многие платы подключают этот сигнал к pulldown, так что TAP-ы JTAG не выходят из сброса, пока они не будут захвачены управлением от адаптера JTAG.
• Возможны режимы драйвер srst_type для сигнала сброса системы (SRST) srst_push_pull и по умолчанию srst_open_drain. Многие платы подключают этот сигнал к pullup, и позволяют переводить этот сигнал в лог. 0 различными событиями, включая появление питания системы и нажатие кнопки сброса.
9.4. Пользовательская обработка сброса (Custom Reset Handling)
У OpenOCD есть несколько методов поддержки разных механизмов сброса, предоставленных технологией чипа и схемой платы. Команды, показанные в предыдущей секции, дают для этого стандартные параметры. Есть также обработчик событий, связанных с TAP-ами или target-ами. Эти обработчики являются процедурами Tcl, которые Вы предоставляете, и которые вовлекаются в разные точки последовательности сброса.
Когда SRST не является опцией, Вы должны настроить для target обработчик события выставления сброса (reset-assert event handler). Например, некоторые адаптеры JTAG не предоставляют сигнал SRST; и некоторые платы имеют несколько target-ов, и не всегда Вы будете хотеть перезагрузить все сразу.
После конфигурирования этих механизмов Вы все еще можете обнаружить, что Ваша плата не стартует и не сбрасывается корректно. Например, может потребоваться незначительно поменять последовательность манипулирования SRST и/или TRST, потому что причудлив механизм адресации reset_config; или выставление обоих сигналов может приводить к улучшенному сбросу, и этому нужно уделить особое внимание.
Поэкспериментируйте с операциями низкого уровня, такими как показанные здесь jtag_reset и jtag arp_*, чтобы найти последовательность операций, которая будет работать. См. раздел [18. Команды JTAG]. Когда Вы нашли работающую последовательность, её можно использовать чтобы заменить ей jtag_init, который срабатывает при старте OpenOCD (см. раздел 7.1. Стадия конфигурации); или init_reset, который срабатывает при обработке сброса.
Вы можете также захотеть предоставить некоторые специфичные для проекта схемы сброса. Например, на платах с несколькими target0-ами стандартная команда reset перезагрузила бы все target-ы, но Вам нужна возможность сбросить только одну target за один раз, и Вы хотите избежать сигнала SRST, действующего на всю плату сразу.
init_reset mode [Overridable Procedure]
Эта процедура вызывается близко к началу команды reset, на практике обычно для предоставления холодного сброса (при включении питания). По умолчанию она также вызывается из jtag_init, если цепочка JTAG не отвечает на основные операции JTAG. Параметр mode указывает на команду сброса низкого уровня (halt, init или run), команду setup, или потенциально может иметь некоторое другое значение.
Реализация по умолчанию просто вызывает jtag arp_init-reset. Замены будут обычно основаны на операциях JTAG низкого уровня, таких как jtag_reset. Здесь операции не должны индивидуально адресовать TAP-ы (или связанные с ними target-ы), пока цепочка JTAG (JTAG scan chain) не будет сначала проверена на работоспособность.
Реализации перед возвратом должны проверить JTAG scan chain. Это делается вызовом jtag arp_init (или jtag arp_init-reset).
jtag arp_init [Command]
Эта команда проверяет цепочку JTAG, просто используя 4 стандартные сигнала JTAG (TMS, TCK, TDI, TDO). Она начинается с выдачи сброса только через JTAG. Затем она выполняет тесты для проверки, что конфигурация цепочки JTAG соответствуют наблюдаемым TAP-ам. Эти тесты включают проверку значений IDCODE на каждом активном TAP-е, и проверку длины их регистров инструкции используя значения TAP -ircapture и -irmask. Если эти тесты пройдены успешно, выдается события TAP setup для всех TAP-ов, которые имеют обработчики для этого события.
jtag arp_init-reset [Command]
Команда делает попытку использовать TRST и SRST для сброса чего-нибудь на JTAG scan chain (и чего-нибудь еще, подключенного к SRST). Она тогда вызывает логику jtag arp_init.
OpenOCD: руководство пользователя, продолжение
OpenOCD: руководство пользователя, окончание |
Комментарии
http://electronix.ru/forum/index.php?showtopic=131148
RSS лента комментариев этой записи