Постоянно сталкиваюсь с проблемой при отладке софта через меню Debug под Microblaze через Platform Cable USB. Версия - ISE и EDK 12.2 с патчами.

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

По неправильному исполнению кода наиболее наглядно - простой цикл.

При запуске в режиме отладки не изменяется счетчик цикла, причем при прохождении в пошаге по окну дизассемблера прыгает в начало цикла с инструкции сохранения.

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

Запускаю неконтролируемое отладчиком исполнение через Run - система работает нормально.

Нет ли идей, в какую сторону копать, что у Xilinx почитать? Может, приоритеты прерываний как-то надо поставить правильно, XCL на SDRAM отключить и все пустить через один канал, или с кэшем еще как-то поколдовать?

Ну соберите для начала "систему", в которой нет ни SDRAM, ни контроллера прерываний - сделайте голый проц с контроллером отладки и каким-нибудь простеньким GPIO.

Почитайте варнинги синтезатора.

Sergey'F, у Вас прерывания используются? У меня что-то похожее было при наличии работающих прерываний . А времени на выполнение прерываний хватает?

Собрать систему, добавляя по кусочкам с нуля и найти баг, с учетом времени компиляции... это мне два дня надо убить. Если ничего не поможет, видимо, придется сделать так.


Да, используются. В порядке снижения приоритета: таймер, контроллер Ethernet lxt971a, debug unit, параллельный порт.
По моим прикидкам и исходя из того, что при run работает, должно времени на обработку прерываний хватать. Посмотрю повнимательнее. А как это может влиять?

Выяснил вот еще: это было при отключенной оптимизации -o0. Включил -o2 - заработало. У человека рядом в другом коде, в другом цикле аналогично было. Но меня это не радует.

Странно мне сие.
Куда там девать 2 дня?

У меня от нажатия generate netlist до получения прошивки проходит 30 минут. Плюс прогнать софт на разных уровнях оптимизации и разных кусках кода, так как я не понимаю, где проблема и могу пропустить. Итого - час на итерацию в одной конфигурации аппаратуры минимум.

Немного не понятен ход отладки.
Я генерирую один раз аппаратную прошивку (somename.bit) и это долго. Далее с помощью SDK заливаю в FPGA. Софт из SDK заливается напрямую в FPGA. Если вы меняете каждый раз аппаратную конфигурацию, то отлаживаться на измененной платформе и с непрерывно меняющейся программой, IMHO, невозможно, так как нет постоянной составляющей в отладке.


Без оптимизации не работает, после оптимизации код стал меньше и быстрее и заработал. Делаем вывод о времени выполнения.

Отлаживаться пошагово при работающих прерываниях, на мой взгляд, дело неэффективное или безнадёжное. Каждая команда сопровождается trap instruction и все времена нарушены. Запросто в исключение можно попасть (бывало такое).

Я представил себе маршрут с созданием простенькой системы, тестированием, потом включением кэшей, тестированием, потом дополнением SDRAM, включением XCL, дополнением модулями-источниками прерываний, и все это тоже постепенно.


Хорошо бы, да я рано радовался - оно все равно заглючило.


Во всех нормальных эмуляторах, с которыми я работал, при возникновении активного запроса прерывания вылетаешь прямо в пошаге в обработчик прерывания, если источник активизируется... Это же не монитор, а встроенный в ядро внутрисхемный эмулятор. Если внешний компонент на шине (тот же таймер, который считает и не знает, что там с процессором) выставил запрос прерывания, ядро должно запустить на выполнение обработчик. Я не прав?

А какие нормальные эмуляторы?
В ядро встроен, как я понимаю, не внутрисхемный эмулятор, а модуль отладки, обеспечивающий доступ к ресурсам. Если не прав, то что это?

Возникло у Вас прерывание от контроллера Ethernet lxt971a, пошли в прерывание, а затем возникло от таймера. Куда идти надо? Стек заполняется ожидающими прерываниями, далее переполнение со всеми вытекающими отсюда последствиями. Таймер же у Вас не минутный, чтобы успеть все прошагать? Я как-то так представляю.

А причем тут стек? Пусть таймер 10000 раз прокрутится и выставит запрос. Контроллер прерываний его обработает и выставит запрос на вход прерывания процессора. Он всего один (одноразрядный). Не буферируется. Просто внешние прерывания пропадают, так как ядро стоит. Я выполняю инструкцию - попадаю в обработчик прерывания. И пусть буфер контроллера Ethernet выставит тоже запрос - если я занимаюсь single-stepping, то это моя проблема - обеспечить, чтобы у него не переполнился буфер. Значит организую поток данных так, чтобы пакеты посылались "дозированно" или вообще выдерну разъем. А даже если я собью работу контроллера Ethernet, ядро все равно не должно перескакивать на неправильную инструкцию.

Я последнее время перед переменными, которые хочу в отладчике понаблюдать, пишу слово volatile - без него отладчик вообще ерунду показывает в значении переменной и код в неправильной последовательности исполняет.

Оптимизацию ставлю только o-2, т.к. o-0 в разы медленнее, а o-3 глючит.




P.S. также volatile пишу перед всеми важными и глобальными переменными - возможно это шаманство и пляски с бубном - но вроде помогает, т.к. с таким словом компилятор точно её не с оптимизирует

По теме: были аналогичные проблемы при пошаговой отладки программы в MicroBlaze. Условные операторы делали неверный переход, происходил переход на совсем другое место кода, счетчики не инкрементировались, обнаруживались неизвестные инструкции, иногда просто elf файл не загружался - не проходил verify. Код и данные размещались в DDR3 памяти.

Проверка показала, что данные в DDR3 бьются по черному. Проблема оказалась в констрейнах. ISE втихоря игнорировал констрейн на глобальный клок системы. После того как констрейн подтянулся - полтергейст сразу пропал.

У меня сейчас работает, но можно немного подробнее рассказать о том, как "констрейн подтянулся" и в чем проявлялось игнорирование констрейна, как это стало понятно? Так как, видимо, причина действительно в этом - у меня стоит SDR и, похоже, глючило от него. Полечилось экспериментами с разными сочетаниями настроек контроллера памяти и калибровкой.

В UCF файле был прописан самый обычный констрейн на входной тактовый сигнал :

В какой-то момент времени я увидел, что в отчете Place and route report -> Timings result он то присутствует, то нет. Причем, если его не было, никакой информации о причине его исчезновения (напрмер, в результате оптимизации цепи) в отчетах я не нашел.

Не было времени разбираться, что и как: плюнул на это дело и написал по старинке (Xilinx говорит, что этот метод устарел и не рекомендуется). Теперь констрейн не пропадает.