Проблемы при отладке в Microblaze, Глючит при пошаговом исполнении в режиме Debug Опции

[Sergey'F]

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

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

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

CODE

int i;
int *p;
int data[4];
...
for (i=0; i<4; i++) p[i]=data[i];
...

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

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

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

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

[Koluchiy]

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

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

[Sergey'F]

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

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

[mdmitry]

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

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

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

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

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

[Sergey'F]

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

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

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

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

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

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

[mdmitry]

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

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

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