при отладке проекта в nios2ide возникла проблема: заглючил то ли программатор, то ли сам отладчик.
например, при загрузке программы в ОЗУ, выкидывает соощение "verify failed at address ..." и отладка не стартует.
иногда отладка стартует, но валится в произвольном месте, не доходя до контрольных точек. может свалиться до входа в main(). потом, после долгого битья в различные бубны, вроде начинает работать, вот сегодня пол-дня отладка проработала, и снова сдохла. при этом нормально работает signal-tap, можно заливать sof и прошивать epcs - все пашет.
а отладчик-ни в какую. поиск по гуглю выдал, что подобная проблема была с usb-blaster ревизии A, и альтера в своих ерратах сей факт отразила (там идет речь о целостности сигналов jtag). у меня ревизия C и беглый осмотр осциллографом проблем не выявил, да и проблема с отладчиком проявляется в произвольное время. единственная пока мысль приходит, что это как-то связано с прерываниями (у меня штук 5 компонентов с прерываниями из них один самописный). могут прерывания наглухо блокировать работу процессора? или проблема с jtag?
у кого-нибудь была похожая фигня?

Озу внутреннее или внешнее?
Если внешнее - соблюдаются ли временf установки/удержания входных и выходных сигналов триггеров в плис и в микросхеме памяти?

ОЗУ внутреннее, с таймингами вроде все нормально.да и клок 40 МГц всего.

Могут(точно не знаю ставится ли запрет на прерывание при загрузке)! Также работа отладчика может быть заблокирована если ваше устройство имеет доступ к памяти и не выключено на момент загрузки программы.

похоже на второй вариант... я обычно делаю так: собираю проект, заливаю его в epcs, потом рестарт и пытаюсь отладить программу... а программа то уже пашет! и есть устройство с прямым доступом к памяти, оно видно и блокирует... интересно, а как в Avalon'е реализована защита от коллизий, когда 2 мастера к одному слейву подключены? надо почитать... спасибо за наводку!

Защита в голове разработчика. Самый простой способ - занять в программе место используемое периферийным устройством массивом.
Сложнее - править скрипты линкера, что учитывая сложные взаимосвязи средств разработки проблематично.

Решение вашей проблемы состоит в отказе от заливки программы при отладке (ищите в настройках отладчика).


epcs - лишнее звено в данной цепочке ( sof заливается из квартуса, а программа из ниоса).

"Защита в голове разработчика" - это вы хорошо сказали. к сожалению ошибки гнездятся там же
я с массивом и сделал, теперь мне кажется, что надо было отдельные блоки on-chip memory под буферы выделить.
про настройку отладчика я вспомнил, есть такая - не заливать программу, а передать ей управление. от epcs совсем уйти не получится - там настройки лежат. а вот sof + загрузка программы в ОЗУ-похоже то, что нужно. проясните мысль про скрипты для линкера, не понял.

ide ниоса формирует файл настроек линкера на основе информации из sopc builder и указанных вами параметров.
Данные параметры можно настроить более гибко, если прописывать все ручками. Например если у вас есть озу 16кб, то система по умолчанию используем все 16кб, а при ручной настройке можно выделить для программы память, расположенную с 1 килобайта по 11 килобайт

хм, интересно. это __attribute__ ((section (".onchip.rwdata"))) что ли? надо копнуть..

2 vadimuzzz

только говорит, что располагать нужно в onchip.rwdata.
На сколько я понял, речь идёт о *.x файлах.

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