История отладки микропроцессора, 1980–2016 гг.

Наконец, вы подключили СППЗУ обратно к целевой плате и включили ее, чтобы проверить, работает ли ваша программа. Если ваша программа работает не так, как ожидалось, тогда у вас было несколько вариантов отладки кода, а именно:

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

Светодиоды: Этот метод используется и сегодня. Если у вас есть светодиоды или любой другой индикатор в целевой системе, вы можете определить путь через свой код, изменив код, чтобы сигнализировать о состоянии в значимых местах кода. Затем вы можете просто посмотреть на светодиоды, чтобы увидеть прогресс (или часто отсутствие прогресса) по вашему коду, что поможет вам определить, на чем сосредоточить свое внимание. (См. Также Когда Life не может предоставить интерфейс отладки, мигайте светодиодом RGB .) Если у вас было несколько запасных цифровых вводов-выводов и вам посчастливилось иметь доступ к логическому анализатору, вы могли бы эффективно отслеживать свой путь через код в реальном времени, отслеживая состояния (местоположения), выводимые вашей программой.

На целевом мониторе: Для тех целевых плат, которые имели последовательный порт (RS232) и достаточно свободного EPROM / RAM для включения программы монитора, вы могли пошагово выполнять свой код на уровне сборки и отображать содержимое регистров и ячеек памяти. Программа монитора фактически была отладчиком низкого уровня, который вы включили в свой собственный код. В каком-то месте вашей программы вы могли бы перейти в программу монитора и начать отладку. Последовательный порт использовался для взаимодействия с программой монитора, и пользователь мог вводить такие команды, как «s» для выполнения инструкции и «m 83C4,16» для отображения содержимого 16 ячеек, например, памяти, начинающейся с адреса 0x83C4. После того, как код работал должным образом, окончательная программа обычно строилась без монитора.

Внутрисхемный эмулятор: Для тех, кто мог себе это позволить, внутрисхемный эмулятор (ICE) был лучшим средством отладки. В некотором смысле этот инструмент предоставлял больше функциональных возможностей, чем современные инструменты отладки, которые предоставляют разработчикам сегодня! ICE заменит ЦП в целевой системе электроникой, имитирующей ЦП. Эти инструменты ICE были большими (намного больше, чем настольный ПК) и очень дорогими - мы говорим о многих тысячах долларов. В то время ICE, как правило, разрабатывался производителем ЦП или одной из основных инструментальных компаний того времени (Tektronix, HP / Agilent, Microtek и т. Д.) И содержал `` связанную '' версию ЦП при эмуляции. . Связанный ЦП буквально имел дополнительные внутренние сигналы, выведенные на контакты на устройстве, так что эмулятор мог одновременно управлять ЦП и получать дополнительную информацию о его внутренней работе. Эмулятор мог наблюдать за операциями, выполняемыми ЦП, и обеспечивать сложные точки останова и функции трассировки, которым сегодня позавидовали бы многие разработчики. Также было возможно заменить область целевой памяти (обычно EPROM) RAM эмуляцией, содержащейся в ICE. Это позволяет загружать код в ОЗУ эмуляции - больше не нужно стирать и выгружать EPROM во время разработки - блаженство!

1982–1990
В 80-е годы разработчик встраиваемых систем претерпел три основных изменения. Во-первых, стало появляться больше интегрированных ИС, содержащих комбинации ЦП, PIC, UART, DMA - все в одном устройстве. Примерами могут служить Intel 80186/80188, который был развитием процессоров 8086/8088 (оригинальный IBM PC), Zilog Z180, который был развитием Z80 (Sinclair Spectrum), и семейство Motorola CPU32 (например, 68302), который был развитием 68000 (Apple Lisa).

Во-вторых, ICE стал намного доступнее для разработчиков. Несколько компаний начали производить инструменты ICE по гораздо более низкой цене, чем системы производителей процессоров. Многие из этих компаний не использовали чипы для облигаций. Хотя это привело к небольшому уменьшению доступной функциональности, это в значительной степени способствовало повышению доступности недорогих продуктов ICE. ДВС для 80186 теперь можно было купить менее чем за 10 000 долларов.

В-третьих, постоянно увеличивающиеся тактовые частоты процессора стали вызывать проблемы для технологии ICE. Это создало серьезные проблемы для кабельных систем, которые использовали ICE, и начало вызывать проблемы с технологией управления эмуляцией, которая просто не могла работать на таких высоких скоростях, не становясь серьезно дорогостоящей (опять же). Производители процессоров также стали более неохотно создавать версии процессоров для закрепления, поскольку дополнительные внутрикристальные соединения мешали работе микросхемы. Решением этих проблем было создание на кристалле схемы управления отладкой ЦП. Это позволяло одношаговый доступ, доступ к памяти и регистрам, а также технологию точки останова для работы на полной скорости ЦП, но в то время не предусматривал трассировку, для которой по-прежнему требовался доступ к контактам интерфейса внешней шины устройства.

Эта трассировка также была менее функциональной, поскольку для многих внутренних периферийных доступов внешняя шина не использовалась. Следовательно, полностью были видны только внешние доступы, а внутренние периферические доступы были темными. Доступ к технологии отладки на кристалле (OCD) осуществлялся либо через проприетарную технологию интерфейса, обычно называемую BDM (Background Debug Mode), либо через стандартный интерфейс JTAG, который более традиционно использовался для производственного тестирования, а не для отладки. Эти интерфейсы позволили компаниям создавать недорогие инструменты отладки для управления работой процессора без ограничений по тактовой частоте. В разных реализациях функции незначительно различались; например, некоторые разрешили инструменту отладки получать доступ к памяти во время работы ЦП, а другие - нет.

1990–2000 гг.
Внешний след практически вымер. Увеличение тактовой частоты ЦП в сочетании с введением внутреннего кеша ЦП сделало внешнюю трассировку практически бесполезной. Однако для диагностики более сложных программных дефектов по-прежнему требовалась возможность записывать путь выполнения ЦП. Задача заключалась в том, как это сделать, используя встроенную логику (чтобы он мог работать на полной скорости ЦП), но при этом передавать данные трассировки с микросхемы с приемлемой тактовой частотой, используя как можно меньше контактов. Решением было преобразовать путь выполнения ЦП в сжатый набор данных, который можно было транспортировать за пределы кристалла и захватывать с помощью инструмента отладки. Затем инструмент может использовать набор данных для восстановления пути выполнения. Стало понятно, что если инструмент отладки имеет доступ к исполняемой программе, сжатие может быть с потерями. Например, если выводились только непоследовательные изменения счетчика программ, инструмент отладки мог бы «заполнить пробелы», используя информацию о выполняемой программе. IBM PowerPC, процессоры Motorola ColdFire, ядра на базе ARM 7TDMI и другие реализовали системы трассировки, основанные на этой концепции.

2000-2010
С появлением сжатых наборов данных трассировки ядра стало возможным выбирать между переносом набора данных за пределы чипа и / или использованием относительно небольшого встроенного буфера трассировки для хранения данных. В начале 2000-х различные поставщики стремились улучшить производительность трассировки; ARM, например, разработала встроенный буфер трассировки (ETB), который был доступен через JTAG и настраивался по размеру для хранения данных трассировки. Это решило проблему обеспечения относительно высокоскоростного порта трассировки вне кристалла (хотя он все еще далек от тактовой частоты ядра) за счет использования кремниевой области в SoC.

В середине 2000-х разработчики встраиваемых процессоров начали реализовывать многоядерные системы. В проектах с использованием ARM IP использовалась технология JTAG, при этом каждое ядро ​​появлялось в последовательной цепочке сканирования JTAG. Это не было проблемой до тех пор, пока не было реализовано управление питанием ядра, в результате чего ядра теряли свое присутствие в цепочке последовательного сканирования JTAG при отключении питания. JTAG не поддерживает появление и исчезновение устройств из цепочки последовательного сканирования, поэтому это вызвало сложности как для инструментов отладки, так и для разработчиков SoC. Чтобы преодолеть это, ARM создала новую архитектуру отладки под названием CoreSight. Это позволило одному порту доступа отладки на основе JTAG (одно устройство в цепочке сканирования JTAG) обеспечить доступ ко многим компонентам CoreSight с отображением памяти, включая все ядра ARM в системе. Теперь устройства, совместимые с CoreSight, можно было свободно отключать, не влияя на цепочку сканирования JTAG (вы можете узнать больше о технологии CoreSight в этом новом техническом документе). Эта технология до сих пор используется в более современных и гораздо более сложных системах на базе IP ARM, которые разрабатываются сегодня.

2010 -
По мере увеличения возможностей встроенных процессоров - особенно с появлением 64-разрядных ядер - стало более возможным поддерживать отладку устройства. Раньше в типичной системе отладки использовались инструменты отладки на мощной рабочей станции, использующие соединение JTAG / BDM с целевой системой для управления выполнением / трассировкой. Поскольку Linux / Android получил широкое распространение, ядро ​​было дополнено драйверами устройств для доступа к встроенным компонентам CoreSight. Теперь с помощью подсистемы perf возможен сбор и анализ трассировки на цели.

С появлением встроенного логического анализатора ARM (ELA) теперь можно вернуться во времена ICE и получить доступ к сложным на кристалле точкам останова, триггерам и трассировке с доступом к внутренним сигналам SoC - точно так же, как старые облигации, которые использовались для предоставления в начале 1980-х.

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