SOPC. Использую Altera Complete Design Suite 9.1.

Попробовал делать то же самое через Nios II IDE. Во время компиляции программы он кладет файл onchip_memory.hex в папку с проектом аппаратной части. И вот, во время перекомпиляции аппаратной части Quartus выводит предупреждение: Warning: Width of data items in "onchip_memory.hex" is greater than the memory width. Wrapping data items to subsequent addresses. Какая настройка за это отвечает, и как избавиться от этой ошибки? Может быть поэтому при прошивке и возникает ошибка Verify failed between address 0x1000 and 0x148B?

Такая ошибка возникает при несовпадении размеров ОЗУ в SOPC и скомпилированного файла программы, который должен там разместиться.
Убедитесь, что все настройки линкера, все сегменты памяти указывают на ваше ОЗУ (onchip_memory).
Также посмотрите карту памяти и размер памяти - всё ли соответствует истине?

Это не ошибка, а предупреждение. На наго вполне можно забить.
Но если очень сильно раздражает, то поиграйте настройками в Assignment - Settings - Compilation Process Settings - More Settings - Reading or Writing Hexadecimal (.hex) File in byte addresable mode
Для того, чтобы сделать эту настройку глобальной, откройте в квартусе редактор hex-файла, и в меню Tools - Options - Memory Editor установите или сбросьте соответствующую галку.

Но с Вашей проблемой все вышеизложенное напрямую не связано.
У Вас, скорее всего, или где-то "ошибка на внимание", или проблема в железе/драйверах.

Для простейшего проекта многое и не требуется: самый простейший проект - это тактовый вход и 5кб памяти. Это чтобы попробовать. Какой у вас чип? На какой пин подаётся тактовый сигнал?


Совершенно верно.

В общем, решил я попробовать сделать все то же самое, только в Nios II IDE. При попытке прошиться из-под него выдавались такие же ошибки... пока я случайно (после чтения темы http://electronix.ru/forum/index.php?showtopic=103410) не заметил, что после компиляции программы IDE (и, видимо, Eclipse тоже) записывает в папку с аппаратным проектом файл onchip_memory.hex. Когда я после очередной неудачной попытки лез в Quartus, что-нибудь менял и перекомпилировал, он подцеплял этот файл, и генерировал .sof уже с прошивкой Nios. Получается, что после конфигурации ПЛИС через Quartus Programmer в устройство уже была залита рабочая программа! А я, следуя инструкциям Альтеры, пытался прошить .elf в уже работающее устройство. Может, дело в этом? В любом случае, если следовать совету Stewart Little из упомянутой темы и загружать проект только через Quartus Programmer, то все работает.

Уважаемые naliwator, Stewart Little, Копейкин, большое спасибо за советы!

Правда, теперь непонятно, как дебажить программу без Eclipse или IDE.

Сообщение отредактировал _Desh_ - Jun 6 2012, 16:27

Нет, не в этом.
Elf должен загружаться в систему с ниосом независимо от того, есть там в памяти что-нибудь, или нету.

Eclipse неправильно считывает параметры зашитого в ПЛИС проекта. Для данной платы есть готовый, абсолютно точно рабочий проект. Я точно знаю, что в этом проекте есть процессор Nios, JTAG UART, system ID. Во-первых, не считывается название процессора. Во-вторых, неверно определяется тип ядра (должно быть, как я понял, 1, 2 или 3, а показывает -1). В-третьих, не находит JTAG UART. Последнее - всегда, вне зависимости от проекта, зашитого в плату, пишет, что реальный system ID - 0xffffffff, хотя базовый адрес компонента System ID Peripheral, базовый адрес памяти определяет верно. Если бы такое наблюдалось только с моим проектом, я бы согласился, что дело или в аппаратной части, или в моих кривых руках. Но с чужим проектом все проще - включается питание, проект загружается из EPCS и плата работает. Моего вмешательства в данном случае - один щелчок тумблером и запуск Eclipse. Вывод - проблема именно в Eclipse, возможно в драйвере USB Blaster. Как считаете, поможет ли переустановка или переход на более новую версию?

Сообщение отредактировал _Desh_ - Jun 8 2012, 05:45

Поставьте последний квартус + еклипс, если не поможет то скорей всего, дело в чьих то руках

Такие фокусы, как невозможность прочесть system ID и timestamp, очень часто случается, когда не
работает или не соответствует ожидаемым параметрам тактовый генератор.
Я, запаяв не рабочий генератор, тоже как-то долго пытался дебажить проект, и тоже не верифицировалась залитая
программа, не совпадал сисид и время создания...
1) Проверьте, на те ли выводы подаётся тактовая частота и работает ли генератор?
2) Проверьте назначение пина для тактовой частоты в проекте.
3) Есть возможность проверить другую плату/рабочий проект?

PS
А версия ква 9.1 довольно таки безглючная...
Мне сюрпризов почти не преподносила.

Сообщение отредактировал Копейкин - Jun 8 2012, 07:46

1) и 2) - генератор рабочий (если верить осциллографу), тактовый вход задан правильно (потому что проект все-таки работает, если загружать его из EPCS или Quartus Programmer'ом). Другой платы нет, а вот другой проект вчера проверял разработчик платы (я ее использую только как отладочную) - все нормально, в смысле если опять же грузить через EPCS, в Eclipse проверить не получится - проект сделан в Nios II IDE 9.0.

Если будет время, попробую накатить сервис пак - вдруг поможет...

Сколько у меня было проблем с NIOSом - все были из за моих кривых рук. Или не правильно соберу в СОПКе схему, или ресет не правильно задам, или не правильно указал вектора. Работал в 3ех версиях квартуса, в каждой получалось запустить ниос.

Desh, я работаю с версией 9.1 SP 2 и у меня глюков мало.
Eclipse работает вполне стабильно.
Изредка отваливается/не стартует консоль Nios, но при следующем запуске, как правило всё ОК.

Небольшой вопрос-уточнение,
как я понял включение галки Small C Library автоматически переключает драйвер для UART из FAST (который с прерываниями работоает) в Small (который Polled). Т.е. комбинаций Small C Library и FAST Driver невозможна.

Т.е. по сути получается что мы можем выводить в UART через printf а читать только через getchar, причем printf будет работать в блокирующем режиме, пока не отправит все байтики код дальше не пойдет.

По сути отличие от Use Lightweight Device Driver API отличие только в том что есть printf. Если он не нужен то лучше и его тоже убить и сэкономить еще пространства для кода в Onchip.

Все ли верно?

В общем, отписываюсь по поводу своей проблемы - дело оказалось в программаторе USB Blaster. Взял (самодельный!) ByteBlaster II (который через LPT) и все заработало, как и должно. Вот такая вот загогулина.