SergeyF 0 9 июня, 2011 Опубликовано 9 июня, 2011 · Жалоба Постоянно сталкиваюсь с проблемой при отладке софта через меню Debug под Microblaze через Platform Cable USB. Версия - ISE и EDK 12.2 с патчами. Вариантов поведения по сути два. Первый - неправильное исполнение кода (пример ниже). Второй - вылет с нормальной инструкции в обработчик исключения неверной инструкции. Проблемы возникают как в пошаге, так и при запуске на исполнение до точки останова. По неправильному исполнению кода наиболее наглядно - простой цикл. int i; int *p; int data[4]; ... for (i=0; i<4; i++) p[i]=data[i]; ... При запуске в режиме отладки не изменяется счетчик цикла, причем при прохождении в пошаге по окну дизассемблера прыгает в начало цикла с инструкции сохранения. Пробовал разные аппаратные конфигурации - отключал в ядре Writeback в кэше данных, играл другими параметрами. Играл с софтом - включал и не включал кеш - эффект один. Стека простейшей программе хватает. Прогнал тест внешней памяти - проходит. Размещал программу и во внешней, и во внутренней памяти - то же. И по быстродействию вроде бы проходит (смотрел отчет), хоть я и не спец в констрейнах Xilinx. Запускаю неконтролируемое отладчиком исполнение через Run - система работает нормально. Нет ли идей, в какую сторону копать, что у Xilinx почитать? Может, приоритеты прерываний как-то надо поставить правильно, XCL на SDRAM отключить и все пустить через один канал, или с кэшем еще как-то поколдовать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Koluchiy 0 9 июня, 2011 Опубликовано 9 июня, 2011 · Жалоба Ну соберите для начала "систему", в которой нет ни SDRAM, ни контроллера прерываний - сделайте голый проц с контроллером отладки и каким-нибудь простеньким GPIO. Почитайте варнинги синтезатора. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mdmitry 0 9 июня, 2011 Опубликовано 9 июня, 2011 · Жалоба Sergey'F, у Вас прерывания используются? У меня что-то похожее было при наличии работающих прерываний . А времени на выполнение прерываний хватает? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SergeyF 0 9 июня, 2011 Опубликовано 9 июня, 2011 · Жалоба Собрать систему, добавляя по кусочкам с нуля и найти баг, с учетом времени компиляции... это мне два дня надо убить. Если ничего не поможет, видимо, придется сделать так. Sergey'F, у Вас прерывания используются? У меня что-то похожее было при наличии работающих прерываний . А времени на выполнение прерываний хватает? Да, используются. В порядке снижения приоритета: таймер, контроллер Ethernet lxt971a, debug unit, параллельный порт. По моим прикидкам и исходя из того, что при run работает, должно времени на обработку прерываний хватать. Посмотрю повнимательнее. А как это может влиять? Выяснил вот еще: это было при отключенной оптимизации -o0. Включил -o2 - заработало. У человека рядом в другом коде, в другом цикле аналогично было. Но меня это не радует. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Koluchiy 0 9 июня, 2011 Опубликовано 9 июня, 2011 · Жалоба Собрать систему, добавляя по кусочкам с нуля и найти баг, с учетом времени компиляции... это мне два дня надо убить. Если ничего не поможет, видимо, придется сделать так. Странно мне сие. Куда там девать 2 дня? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SergeyF 0 9 июня, 2011 Опубликовано 9 июня, 2011 · Жалоба Странно мне сие. Куда там девать 2 дня? У меня от нажатия generate netlist до получения прошивки проходит 30 минут. Плюс прогнать софт на разных уровнях оптимизации и разных кусках кода, так как я не понимаю, где проблема и могу пропустить. Итого - час на итерацию в одной конфигурации аппаратуры минимум. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mdmitry 0 10 июня, 2011 Опубликовано 10 июня, 2011 · Жалоба У меня от нажатия generate netlist до получения прошивки проходит 30 минут. Плюс прогнать софт на разных уровнях оптимизации и разных кусках кода, так как я не понимаю, где проблема и могу пропустить. Итого - час на итерацию в одной конфигурации аппаратуры минимум. Немного не понятен ход отладки. Я генерирую один раз аппаратную прошивку (somename.bit) и это долго. Далее с помощью SDK заливаю в FPGA. Софт из SDK заливается напрямую в FPGA. Если вы меняете каждый раз аппаратную конфигурацию, то отлаживаться на измененной платформе и с непрерывно меняющейся программой, IMHO, невозможно, так как нет постоянной составляющей в отладке. Выяснил вот еще: это было при отключенной оптимизации -o0. Включил -o2 - заработало. У человека рядом в другом коде, в другом цикле аналогично было. Но меня это не радует. Без оптимизации не работает, после оптимизации код стал меньше и быстрее и заработал. Делаем вывод о времени выполнения. Отлаживаться пошагово при работающих прерываниях, на мой взгляд, дело неэффективное или безнадёжное. Каждая команда сопровождается trap instruction и все времена нарушены. Запросто в исключение можно попасть (бывало такое). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SergeyF 0 10 июня, 2011 Опубликовано 10 июня, 2011 · Жалоба Немного не понятен ход отладки. Я генерирую один раз аппаратную прошивку (somename.bit) и это долго. Далее с помощью SDK заливаю в FPGA. Софт из SDK заливается напрямую в FPGA. Если вы меняете каждый раз аппаратную конфигурацию, то отлаживаться на измененной платформе и с непрерывно меняющейся программой, IMHO, невозможно, так как нет постоянной составляющей в отладке. Я представил себе маршрут с созданием простенькой системы, тестированием, потом включением кэшей, тестированием, потом дополнением SDRAM, включением XCL, дополнением модулями-источниками прерываний, и все это тоже постепенно. Без оптимизации не работает, после оптимизации код стал меньше и быстрее и заработал. Делаем вывод о времени выполнения. Хорошо бы, да я рано радовался - оно все равно заглючило. Отлаживаться пошагово при работающих прерываниях, на мой взгляд, дело неэффективное или безнадёжное. Каждая команда сопровождается trap instruction и все времена нарушены. Запросто в исключение можно попасть (бывало такое). Во всех нормальных эмуляторах, с которыми я работал, при возникновении активного запроса прерывания вылетаешь прямо в пошаге в обработчик прерывания, если источник активизируется... :( Это же не монитор, а встроенный в ядро внутрисхемный эмулятор. Если внешний компонент на шине (тот же таймер, который считает и не знает, что там с процессором) выставил запрос прерывания, ядро должно запустить на выполнение обработчик. Я не прав? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mdmitry 0 10 июня, 2011 Опубликовано 10 июня, 2011 · Жалоба Во всех нормальных эмуляторах, с которыми я работал, при возникновении активного запроса прерывания вылетаешь прямо в пошаге в обработчик прерывания, если источник активизируется... :( Это же не монитор, а встроенный в ядро внутрисхемный эмулятор. Если внешний компонент на шине (тот же таймер, который считает и не знает, что там с процессором) выставил запрос прерывания, ядро должно запустить на выполнение обработчик. Я не прав? А какие нормальные эмуляторы? В ядро встроен, как я понимаю, не внутрисхемный эмулятор, а модуль отладки, обеспечивающий доступ к ресурсам. Если не прав, то что это? Возникло у Вас прерывание от контроллера Ethernet lxt971a, пошли в прерывание, а затем возникло от таймера. Куда идти надо? Стек заполняется ожидающими прерываниями, далее переполнение со всеми вытекающими отсюда последствиями. Таймер же у Вас не минутный, чтобы успеть все прошагать? Я как-то так представляю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SergeyF 0 10 июня, 2011 Опубликовано 10 июня, 2011 · Жалоба Возникло у Вас прерывание от контроллера Ethernet lxt971a, пошли в прерывание, а затем возникло от таймера. Куда идти надо? Стек заполняется ожидающими прерываниями, далее переполнение со всеми вытекающими отсюда последствиями. Таймер же у Вас не минутный, чтобы успеть все прошагать? Я как-то так представляю. А причем тут стек? Пусть таймер 10000 раз прокрутится и выставит запрос. Контроллер прерываний его обработает и выставит запрос на вход прерывания процессора. Он всего один (одноразрядный). Не буферируется. Просто внешние прерывания пропадают, так как ядро стоит. Я выполняю инструкцию - попадаю в обработчик прерывания. И пусть буфер контроллера Ethernet выставит тоже запрос - если я занимаюсь single-stepping, то это моя проблема - обеспечить, чтобы у него не переполнился буфер. Значит организую поток данных так, чтобы пакеты посылались "дозированно" или вообще выдерну разъем. А даже если я собью работу контроллера Ethernet, ядро все равно не должно перескакивать на неправильную инструкцию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VladimirB 1 11 июня, 2011 Опубликовано 11 июня, 2011 · Жалоба Постоянно сталкиваюсь с проблемой при отладке софта через меню Debug под Microblaze через Platform Cable USB. Версия - ISE и EDK 12.2 с патчами. ... При запуске в режиме отладки не изменяется счетчик цикла, причем при прохождении в пошаге по окну дизассемблера прыгает в начало цикла с инструкции сохранения... Я последнее время перед переменными, которые хочу в отладчике понаблюдать, пишу слово volatile - без него отладчик вообще ерунду показывает в значении переменной и код в неправильной последовательности исполняет. Оптимизацию ставлю только o-2, т.к. o-0 в разы медленнее, а o-3 глючит. P.S. также volatile пишу перед всеми важными и глобальными переменными - возможно это шаманство и пляски с бубном - но вроде помогает, т.к. с таким словом компилятор точно её не с оптимизирует :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
chipovod 0 27 января, 2012 Опубликовано 27 января, 2012 · Жалоба По теме: были аналогичные проблемы при пошаговой отладки программы в MicroBlaze. Условные операторы делали неверный переход, происходил переход на совсем другое место кода, счетчики не инкрементировались, обнаруживались неизвестные инструкции, иногда просто elf файл не загружался - не проходил verify. Код и данные размещались в DDR3 памяти. Проверка показала, что данные в DDR3 бьются по черному. Проблема оказалась в констрейнах. ISE втихоря игнорировал констрейн на глобальный клок системы. После того как констрейн подтянулся - полтергейст сразу пропал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SergeyF 0 31 января, 2012 Опубликовано 31 января, 2012 · Жалоба Проверка показала, что данные в DDR3 бьются по черному. Проблема оказалась в констрейнах. ISE втихоря игнорировал констрейн на глобальный клок системы. После того как констрейн подтянулся - полтергейст сразу пропал. У меня сейчас работает, но можно немного подробнее рассказать о том, как "констрейн подтянулся" и в чем проявлялось игнорирование констрейна, как это стало понятно? Так как, видимо, причина действительно в этом - у меня стоит SDR и, похоже, глючило от него. Полечилось экспериментами с разными сочетаниями настроек контроллера памяти и калибровкой. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
chipovod 0 1 февраля, 2012 Опубликовано 1 февраля, 2012 · Жалоба В UCF файле был прописан самый обычный констрейн на входной тактовый сигнал : NET "CLK" TNM_NET = sys_clk_pin; TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 200000 kHz; В какой-то момент времени я увидел, что в отчете Place and route report -> Timings result он то присутствует, то нет. Причем, если его не было, никакой информации о причине его исчезновения (напрмер, в результате оптимизации цепи) в отчетах я не нашел. Не было времени разбираться, что и как: плюнул на это дело и написал по старинке (Xilinx говорит, что этот метод устарел и не рекомендуется). Теперь констрейн не пропадает. NET "CLK" PERIOD = 5 ns; Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться