Собственно сам вопрос в заголовке темы.

Есть некоторая система на циклоне 3 с ниос процессором на борту. Конфигурация такая: загрузка идёт из epcs вектор старта программы прописан на внутреннее озу (другого нет). То есть по включению питания программа и конфигурация грузятся прямо в плис и всё стартует и работает нормально. Теперь если нажать на кнопку сброс процессора (она сделана как вход на внешнем пине плис) то система сбрасывается, видно по периферии, то-есть сброс проходит, но далее система висит в этом состоянии, программа не стартует и проект не работает. При этом если я из иде ниоса загружаю программу для отладки и запускаю ёё все стартует и работает далее, или если я по новой через jtag загружу конфигурацию тоже всё стартует и работает. Таким образом видно что не выполняется старт программы из внутреннего озу после сброса.

Вот и вопрос, что я где пропустил или не дочитал? Чего ему (проекту) не хватает?

А вы не модифицируете случаем код во время исполнения ??

пЫсЫ.
А что говорит моделирование ??

Нет, код не модифицирую, но почти вся периферия работает с прямым доступом к памяти, 5 блоков на запись и 3 блока на чтение, кроме процессора. Сама пишет и читает данные из ОЗУ, однако она вся имеет бит включения, который сбрасывается по сбросу сигналом reset шины avalon. То есть по идее после сброса она висит и ждёт пока ее обратно проинициализируют. И вот эта инициализация похоже и не наступает!
Хотя после старта программа процессора первым делом и должна настроить периферию.

А о каком моделировании идёт речь? Каждый модуль по отдельности отлажен в модельсиме.
Весь проект в модельсиме не гонял, думаю не потянет. Всего более 7000 вентилей.

можно попробовать signaltap`ом старт отследить
www.altera.com/literature/an/an446.pdf
что происходит с ниосом/программой. железо по возможности исключить из рассмотрения, просто помигать пином.

Поставте вектор сброса на eps контроллер. А вектор исключения можете оставить в ОЗУ.

Спасибо за советы! Документ почитаю, однако пробовать буду только во вторник (праздники). На счёт поставить вектор на epcs думаю не поможет! У меня озу расположено не с нулевого адреса, а с 0x10000, а с 0 как раз epcs, то есть если даже по нулевому адресу произойдёт несанкционированная запись, типа как в АВР в еепром, то программа просто так в epcs не запишет, а до 0x10000 адреса она вряд ли дойдёт, так как находится в состоянии сброса. Кстати проверка размеров буферов на переполнение перед записью проходит в железе (на уровне периферии).

Ладно почитаю документ... буду думать...! А пока всех с праздником! Христос воскрес! Пьяный я уже.... 8)

это еще бабушка надвое сказала: писать в EPCS напрямую, конечно, не получится, но нагадить можно. контроллер EPCS - это по сути контроллер SPI, у них даже регистры совпадают. поэтому есть вероятность записать мусор в управляющие регистры(они как раз там адресуются). с проверкой размеров буферов я раз тоже нарвался (не проверил size>0 перед записью, потом долго веселился, signaltap выручил).

У меня в программе пока работы с epcs нет вообще! То-есть я вообще не использую никакие функции для работы с epcs, поэтому по моему я ему никак навредить не могу.
На счёт размеров буферов, да проверки на > 0 у меня нет. Но я в самом начале наступил на грабли, когда запустил периферию до её конфигурации, адреса буферов после сброса были равны 0 и у меня стиралась рабочая программа в озу. После этого я в периферию добавил бит включения, который взводится последним, после того как я настрою все адреса и размеры, поэтому не вижу криминала в отсутствии проверки размеров на > 0. По сбросу естественно биты включения периферии сбрасываются и это видно по тому, что все модули останавливаются и ждут инициализации.

а не надо никаких функций, регистры контроллера EPCS ведь memory-mapped. сбой в работе с памятью=>некорректная запись в регистры=>есть вероятность записи/стирания страницы. это касается не только EPCS, можно нагадить в любое устройство. проверка на size>0 нужна, если счетчики адресов в железе декрементятся.

Правильно тебе советуют - вектор сброса должен быть на EPCS. То что EPCS - простая MM это не правильно. Можеш проверить из программы записать и прочитать её как память нельзя, только через API/HAL. Чтобы зашить туда программу нужно собрать систему в sopc builder с epcs-контроллером, вектор сброса на epcs. А потом зашить её flash programmerom.

"То что EPCS - простая MM это не правильно." - не понял фразы. Что значит простая MM? Стандартный альтеровский компонент, какой она его сделала такой и есть.
У меня система и так собрана в sopc builder с epcs-контроллером. Да вектор сброса не стоит на epcs потому как мне не нужен загрузчик из epcs. Зачем мне грузить программу из epcs после конфигурирования если я могу загрузить ее во время конфигурации. Тут возникает другой вопрос, насколько загрузчик из epcs (программный) быстрее или медленнее загрузит прогу, чем это делается при конфигурировании?

И еще попутно тогда вопрос на счёт размера программного кеша, если у меня программа вся влазит во внутреннее озу, или если не влазит, какой размер кеша выбирать (критерий выбора), если вся влазит, то по идее размер должен быть чуть больше чем сама программа (с другой стороны, если вся программа влазит в озу, то зачем тогда кеш вообще ?), а если не влазит не понятно, и насколько упадёт производительность процессора учитывая что программа будет исполняться из epcs. Сейчас система работает на 80 МГц. И возможно ли в таком случае (если программа исполняется из epcs) писать в него данные (сохранять в него настраиваемые данные)?

P.S. По сути вопроса, пока со сбросам далее не разбирался - не до этого. Проект в активной фазе, пока разбираюсь с проблемами решение которых понятно. По тёмным пятнам пока готовлюсь. 8-)

"То что EPCS - простая MM это не правильно." - это я имел ввиду что epcs - нелинейная память. Её нельзя читать/писать вот так:

alt_u8* ptr;
prt = (alt_u8)EPCS_BASE;
*prt = 0x58;

То есть написать и скомпилировать можно, а результата не будет.

По теме вопроса не понял как ты вообще зашиваешь прогу в EPCS, к .jic или .pof файлу её прикрепляешь или flash programmerom из NIOS IDE?

"Её нельзя читать/писать вот так:" - ну это было понятно из документации, только через АПИ. Поэтому я и говорил что раз не пользуюсь АПИ для епцс то и не вижу возможности его испортить.

Сейчас я компилирую проект в ниосе, который создаёт хекс файл, который в свою очередь используется как инициализационный для внутренней памяти. Вот собственно и всё. После этого когда квартус генерит pof файл для епцс в него уже входит всё и собственно конфигурация плис и инициализация памяти. Затем после включения питания сразу грузится из епцс конфигурация и память и всё стартует!

И потом при отладке я просто из ниоса заливаю новую программу сразу в озу, не в епцс и тоже всё работает!
А вот если я нажму на кнопку сброс, то система сбрасывается и висит в этом состоянии пока я снова не залью прошивку(программу) из иде ниоса и не запущу её из иде.

Тут у меня возникла мысля. А не может это быть связано с тем что если происходит сброс, то стартовый адрес для программы сбрасывается в 0, где у меня епцс а не программа, хотя по идее система должна об этом знать что сбрасывать адрес программы надо не в 0, а в 0х1000 где у меня озу.

API-это просто обертка для доступа к управляющим регистрам. сама EPCS - не memory-mapped, а вот управляющие регистры - таки да. записав в эти регистры мусор(через IOWR, например), можно инициировать запись/стирание. но это с какой-то вероятностью. посмотрите код драйвера для EPCS, там все совершенно прозрачно. + сравните описание регистров EPCS и SPI контроллеров.


flash programmer -ом не пользуетесь? имхо, удобнее.
www.altera.com/literature/ug/ug_nios2_flash_programmer.pdf


а, вроде понятно. видимо, ресет подключен только к ниос? а вектор сброса указывает на внутреннее ОЗУ? тогда "это не баг, это - фича". сделайте вектор сброса на EPCS, пользуйтесь flash programmer-ом для обновления и будет вам счастье. загружать программу из ниос-иде во внутреннее ОЗУ и отлаживать в железе будет по-прежнему возможно. да, еще выложите картинку из SOPC-билдера и настройки линкера(в свойствах System Library в ниос иде)

Отчитываюсь! Со сбросом разобрался. Всё работает!

Пришлось основательно проштудировать an458. Подключил стартер кит прошёл всё по шагам.

По ходу прочтения данного документа узнал много нового про загрузку и про отладку начиная с entry point.

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

После прочтения an458 решил немного переделать систему. Отделил память данных от памяти программы (для надёжности). Память программ сделал reed only. Естественно память программ к периферии не подключена. Обмен данными между процессором и периферией идет через отдельный блок озу. Тем не менее при подключении пишущей периферии система после сброса продолжила виснуть!!!

Вылечилось ТОЛЬКО после добавления проверки адреса записи у мастера на > 0.

Примерно вот такой код:
assign avm_mcuiface_address = {addr[31:2], 2'b0}; // Lower address bits are not used assume world aligned addresses

wire addr_set = (addr[31:2] > 30'd0); // !!! Это оно !!!

...
и в always

if(addr_set) avm_mcuiface_write_n <= 1'b0; // Start the write cycle

И примерно такая проверка в каждой пишущей периферии!

Причём висло на какой-то системной функции alt_sys_tiks - точно не помню, помню что tiks.

Каким образом оно влияло, понять не могу! Переполнения буферов нет точно! Включается периферия только после настройки! Так что единственное что приходит на ум это что адрес сбрасывается быстрее чем сигнал write. Но и в этом случае даже пусть оно испортит буферное озу по 0 адресу - программу это не затронет, так-как она в другом блоке не имеющем связи с периферией. После старта программа по идее всё проинициализирует по новой и ей всё равно что находится в озу. Тем не менее факт есть факт! Работает ТОЛЬКО после вышеперечисленных манипуляций с периферией!


Теперь попутно возник еще вопрос. После изучения еще кучки документов что-то я не понял может-ли исполняться код из епцс или нет. Судя по сопк билдеру епцс может подключаться как источник инструкций для процессора, но что-то я нигде не видел примера как он выполняет из него инструкции. Не загрузчики! С загрузчиками всё понятно просто копируют из епцс код в другую память и передают управление. Интересует именно исполнение инструкций как из CFI flash в терминах альтеры прямо из памяти епцс.

Может без проблем. В свойствах линкёра выбираешь для программы и RO-памяти epcs. Только для RW надо другую память всё равно - одной epcs не обойдёшся.