Всем доброго дня!
Делаю новый проект с nios,похоже снова что то напутал,застрял на загрузке.
После включения питания и загрузки хард-части начинает грузиться софт-часть,но как-то странно.На линии epcs_flash_controller_dclk идут пачки клока по 8 тактов и интервалом 2 мкс,этот процесс длится примерно 8 секунд после чего полная тишина.Причём линия epcs_flash_controller_sce так и остаётся в нуле. Мемори-эдитором смотрел область памяти - там только 0xFF ,т.е. загрузки из epcs не происходит.Посмотрите,плз,нет ли ошибок в qsys.

2 _Anatoliy
тут надо бы ещё лог сообщений Qsys (если есть варнинги), настройки NIOS2 и сообщения при сборке - какие там варнинги по ходу дела. А так если не ругается Qsys - значит 100% дело в настройках а не в соединении.

Спасибо! Qsys при сборке выдаёт 4 варнинга,один о том что не задействовано прерывание SPI, и три касаемо епцс-загрузчика.Но что они означают?

Вот настройки корки ниос.

Альтера говорит что подобные варнинги вроде можно игнорировать.

2 _Anatoliy
На счёт варнингов - так оно и есть, это частично AV-ST интерфейс, он вам не надо.
В принципе классическая конфигурация, как по документам, должен быть автоматом сгенерирован загрузчик и всё должно работать.
А версия софта у вас какая (там просто в 13м квартусе помнится epcs_flash_controller сильно "доработан" - не исключено что что-то поломали когда "дорабатывали")? Если 13я - возможно есть смысл откатиться на более позднюю версию..

Квартус 12.1
А таки похоже что-то в qsys не сростается.Не меняя ничего остального просто добавил в qsys ещё три компонента : sysid,jtag_uart и spi_slave - поведение изменилось коренным образом.Теперь после взвода CONF_DONE вообще нет обращения к epcs.Я в шоке - каждый новый проект как новый бой.Что ещё можно сделать?Пока попробую с нуля собрать qsys(сейчас использовал заготовку от прошлого проекта).

Можно в принципе попробовать в 9/10 квартусе - там точно всё работало, потом посмотреть хекс-файло которое сделано в новой и в старой вериях. Возможно его замена в 12й версии даст какие то результаты..

у ксалинкса взять старый проект и адаптировать под новый - 100% гарантия глюков. Всегда проект делаю заново, и ксалинкс еще библиотеки перекомпиливает постоянно под разные конфигурации с отладкой и без, потому старое в новое - лучше заново. Думаю что они не сами это придумали и у альтеры подобные проблемы)

А EPCS-ку каким образом прошивали?
Если мне склероз не изменяет, с каких-то 12-х версий FlashProgrammer начал вести себя непонятным образом, и приходилось прошивать конфигуратор через JIC (предварительно нужно было преобразовывать sof и elf в формат flash, затем из flash в hex, затем объединять оба этих hex'а в jic).

Ага,примерно так и делаю - sof и elf в формат flash, затем из эльфовской flash в hex, затем объединяю hex и sof в jic.
Посмотрите,плз,скрипт на наличие косяков.

Вот отчёт :

Пересборка qsys и bsp с нуля ничего не дала,на линии epcs_flash_controller_dclk идут пачки клока по 8 тактов и интервалом 2 мкс,этот процесс длится примерно 8 секунд после чего полная тишина.Причём линия epcs_flash_controller_sce так и остаётся в нуле.
Я правильно понимаю что если epcs_flash_controller используется только для загрузки программы то его выход прерывания можно не подключать?
Ещё добивает что предыдущий проект я делал именно в Q12.1 и всё загружалось и работало... И скрипты те же...

Только камень другой,в прошлом проекте был EP3C55F484, а в новом EP3C25E144.Жаль железа уже нет,проверил бы на старом камне.

Совет прост.
Начните отладку с ончип памяти!
Причём убедитесь, что в начале она инициализируется реальным hex файлом, чтобы при старте и до прогрузки из Эклипса ниос не сошёл с ума от мусора в ончипе.
Когда всё заработает - копайте в сторону скриптов и интерфейса FlashProgrammer.
Бывало, что иногда только через меню получалось зашиться во флеш через программер, а скриптами - нифига. Разбираться было некогда.
К тому же Эклипс умеет генерить сразу готовый файл .flash.

Спасибо!В том то и дело что ончип память не инициализируется - epcs_flash_controller читает что-то из епцс целых 8 секунд,после этого в памяти нули. Я сейчас попробовал из Эклипса по jtag в режиме отладки приконнектиться,пишет что ошибка при загрузке.Вот репорт:

Как это понять?Может это быть причиной?

Стандартный вопрос - брюхо у EP3C25E144 не забыли к земле припаять?

Не,это святое

1. Ну а конфигурация ПЛИСки происходит корректно? CONF_DONE и INIT_DONE взводятся?
2. А если сперва залить конфигурацию по JTAGу, то после этого будет с эклипсом коннектиться?

1). Всё корректно и всё взводится.
2). Так тоже не коннектится.

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

А в настройках bsp случайно галка "Allow code at reset" не взведена?

Блин,взведена... Не нужно было?

После того как убрал эту палку ситуация изменилась. После взвода CONF_DONE обращения к епцс совсем нету секунд 20.После этого начинается какой-то обмен с епцс и идёт бесконечно долго.

Зато по Jtag вроде законнектился,спасибо.Завтра досмотрю.

а че альтеры правда к земле дном корпуса припаиваются?

Честная, святая правда!
И не припаявший будет горько о том сожалеть.

че прям кладешь микруху и паяльником-феном греешь? как БГА? как ей пузо то нагреть?

вот же придумают супостаты....

Ну не хватило ног у корпуса для земли. Вот ее на exposed pad и вывели
А паять - да, можно феном. Только при этом еще и плату подогревать надо (у меня из строительного фена сделан прехитер, а монтажный фен используется по назначению ).


Разумеется - если у Вас используется epcs_flash_controller, то эту галку взводить не надо.
При взведении этой опции линкер будет располагать сегмент кода по адресу сброса, а там у Вас ПЗУ epcs_flash_controller'а, в котором копировщик лежит.
Таким образом - конфликт налицо

Ясно,спасибо! С JTAG сейчас проблем нет,коннектится нормально. А вот с epcs_flash_controller проблема так и осталась,загрузка в onchip ram не выполняется,хотя обращение к епцс есть. Нет ли у Вас ещё каких мыслей?

Вот захватил сигналы on-chip-ram, видно что epcs_flash_controller всё-таки записывает данные в память,причём данные соответствуют содержимому епцс и идут в нужном порядке. При этом мемори-эдитор показывает что в памяти либо нули либо 0хFF и ниос не работает. Бред какой-то...

а содержимое флешки проверяли?

После программирования выполняется контроль CRC,всё нормально.
Тут очень похоже что epcs_flash_controller считывает данные в on-chip-ram , но после этого он не останавливается а продолжает шелестеть дальше. И on-chip-ram по новой забивается 0хFF из пустой области епцс. Это видно осциллом,клок на епцс идёт порядка 5-8 секунд. Коллеги,можете подсказать кто и каким образом указывает epcs_flash_controller-у количество байт данных , которое он должен считать?

Так и есть,если тормознуть epcs_flash_controller на некоторое время и просмотреть содержимое on-chip-ram то можно увидеть загруженный код.
Правда выглядит он как-то для меня непонятно. Вот листинг стартовой секции:

Память on-chip-ram – 0x00008000…0x0000FFFF
1). В 32-битных словах из памяти наблюдается сдвижка на идин байт.
2). Весь блок кода должен начинаться с восьмого адреса on-chip-ram,реально начинается с адреса 0х800.
Кто нибудь разбирался как реально мапится код в on-chip-ram?

исходники загрузчика есть в составе квартуса, можете сравнить с дизассемблером. такое впечатление, что баг программатора (заголовок битый или типа того). а вы оба способа пробовали - с jic и с nios2-flash-programmer?

upd: и да, crc - не показатель, я помню минимум 2 версии квартуса с корявым загрузчиком, контрольная сумма-то совпадает, только образ изначально битый/кривой. имеет смысл тот же проект прогнать на другой версии ПО

Спасибо!
Я пробовал только с jic и Run As. При выполнении Run As ниос работает нормально. А nios2-flash-programmer я ещё не пользовал,как-то обходился без него. Сейчас попробовал законнектиться - результат на картинке. От чего это может быть? Подскажите, плз, что ещё можно сделать?

галочки поставьте, чтоб он игнорировал ID и прочее

Значит это допустимая ситуация?
Пробовал ставить флажки ,но кнопка Start после refresh остаётся недоступной.

Вот что-то каши много теперь стало.
1 - я предлагал грузиться имеено из ончипа! Сразу! Это когда ончип память инициализируется вашим кодом для Ниоса сразу. Это hex файл подключить надо в Qsys при создании самой ончип памяти.
2 - Раз теперь загрузка есть - смотрите, что вам генерит программер.
Его нутро не сложное и по коду множно понять где заголовок загрузчика, какого размера сам код, где закончился код, что доливается после кода до кратного числа в память. Там вроде всё просто. Бывало - приходилось писать свой генератор .bin файлов для заливки во флеш память. По разным причинам. Но удалось и всё работает. Возможно, что размер указан неверно. Или у программера указано перелить всё содержимое флеши в ончип.
У альтеры есть мануал по способам загрузки:
Alternate Nios Boot Methods. Может покурить его. Ну и багрепорт почитать.

Сразу после добавления проекта Квартус в Hardware Connections появляются такие ошибки.


Это hex файл перед подключением нужно переделать?У того что у меня сейчас стартовый адрес 0х8020.

Его нужно получить их эклипса. Результат компиляции вашего ПО для Ниоса. Сейчас не могу сказать, где там эти галочки.

Флажок enable_alt_load в настройках bsp?Попробовал несколько вариантов,всегда у *.hex стартовый адрес 0х0003EE53.

да, вообще не понимаю, зачем все это нужно. во всяком случае, с этим можно потом разобраться

в консоли вбейте: nios2-flash-programmer --verbose
если покажет, что видит регистры EPCS, то накидайте скрипт а-ля:

и забудьте про этот корявый эклипсовский гуй

Огромное спасибо!
Вот уважаю такие бескомпромиссные ответы.
Сейчас попробую,только скажите как выбрать EPCS_BASE?

Так это же адрес из системы Qsys для EPCS.

Я не понимаю, отчего у вас получаются разные адреса в Qsys и в hex. Может в этом и косяк. Я с Ниосом работаю только в Quartus 11.1sp2.

Адрес чего?Епцс-контроллера?Для чего кому-то знать какой адрес на шине имеет контроллер?
Я выше приводил скрипты,там ключа --base нет,скрипты брал на www.naliwator.narod.ru
Пока беру тайм-аут,буду переустанавливать ОС на компе.

именно, сам адрес можно взять в system.h или из QSys выдернуть. смысл в том, что nios2-flash-programmer шьет "на горячую",
используя контроллер EPCS (который на самом деле SPI). кстати, забыл написать, что sof уже должен быть загружен
(при первой прошивке можно использовать nios2-configure-sof). при последующих манипуляциях sof нужно подгружать только если сменится адрес контроллера

Ясно,спасибо!
Переустановил у себя ОС,Квартус и т.д.
Е.М.Н.И.П раньше скрипты были в файлах *.sh например elf2flash.sh , сейчас же есть только elf2flash без расширения с загадочным содержимым:

Или так и должно быть и память опять подводит? WinXP32.
Кстати,а чем плох метод предложенный warrior-2001? По моему это самый короткий путь. Правда у меня ещё не получилось сделать *.hех из *.elf для инициализации ram , отвлекаюсь постоянно.

Отвечу сам пожалуй.

Минус в том, что ПО для процессора по сути хранится в самой конфигурации ПЛИС.

И если захотите сменить ПО, не меняя прошивку(а вы захотите ), то придётся перекомпиливать весь проект в квартусе с новым hex файлом.

Так что в моём случае - это лишь первый этап.

hex можно обновить и без полной пересборки проекта.

А Вы не правы. Ведь есть же такая чудесная команда как Update Memory Initialization File.


Таки память меня подвела,скрипты нормальные.

Ваш метод заработал с полоборота
Спасибо!

это тоже shell-script, в *nix расширения не обязательны

мне скрипт удобнее тем, что он хоть напишет, если что не так пошло. а квартусовский программер выкинет что-нибудь типа "JTAG error $*&^*#%" и сиди думай. а еклипсовские приблуды имеют свойство падать вообще молча (не все, зависит от версии и погоды на Марсе).

Это да,но команду Update Memory Initialization File можно и скриптом выполнить.
Помогите,плз,разобраться с прерываниями.Получается так что прерывания возникают всегда,даже когда нет принимаемых данных.Как такое может быть,ведь при чтении данных флаг RRDY сниматься должен?

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

С чем это может быть связано?

либо в железе глюк (надо лезть сигналтапом в потроха контроллера SPI), либо SPI_SLAVE_BASE куда-то не туда показывает (например, сменились адреса в Qsys).

Ага,спасибо,уже иду по следу...

Коллеги,ещё один вопрос остался.Касается ниосовского SPI_slave,у него запрос прерывания формируется по окончанию сигнала SS.
Таким образом под SS может быть до 4-х принятых байт.А если нужно принять команду из 6 или 10 байт?Самому писать SPI_slave?Или дробить команду на несколько посылок? Как поступаете?И совсем не понятно как при таком построении выполнять чтение данных по указанному адресу.

я свой контроллер SPI писал, с картами и блудницами. прерывания, правда, не делал - мне надо было только чтоб пакет любой длины был, но не вижу проблемы

Спасибо!
Насчёт своего контроллера понятно,можно сделать такой какой хочется.Я думал может штатный всё же удастся применить.