Вопрос по сбросу Nios процессора?, Не хочет стартовать после сброса? Опции

[inco]

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

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

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

[sanjaaaa]

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

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

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

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

[inco]

"То что 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 где у меня озу.

[vadimuzzz]

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

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

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

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

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

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

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

[inco]

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

Пришлось основательно проштудировать 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 в терминах альтеры прямо из памяти епцс.