[_Desh_ 0]

А Вы хардверную часть делаете в SOPC'е или в Qsys'е?

 

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

[_Desh_ 0]

Попробовал делать то же самое через 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?

[Копейкин 0]

Такая ошибка возникает при несовпадении размеров ОЗУ в SOPC и скомпилированного файла программы, который должен там разместиться.

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

Также посмотрите карту памяти и размер памяти - всё ли соответствует истине?

[StewartLittle 41]

И вот, во время перекомпиляции аппаратной части Quartus выводит предупреждение: Warning: Width of data items in "onchip_memory.hex" is greater than the memory width. Wrapping data items to subsequent addresses. Какая настройка за это отвечает, и как избавиться от этой ошибки?

Это не ошибка, а предупреждение. На наго вполне можно забить.

Но если очень сильно раздражает, то поиграйте настройками в Assignment - Settings - Compilation Process Settings - More Settings - Reading or Writing Hexadecimal (.hex) File in byte addresable mode

Для того, чтобы сделать эту настройку глобальной, откройте в квартусе редактор hex-файла, и в меню Tools - Options - Memory Editor установите или сбросьте соответствующую галку.

 

Но с Вашей проблемой все вышеизложенное напрямую не связано.

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

 

[naliwator 0]

Для примеров наверняка нужна отладочная плата? У меня ее нет и не будет. Если получится завтра какой-нибудь готовый проект запустить на доступной мне плате, то попробую.

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

 

Да, кстати. На той плате, с которой я упражняюсь, стоит EPCS с прошитым в ней другим проектом. Я пытаюсь на лету зашивать в ПЛИС свой .sof файл через JTAG, а затем и .elf, чтобы не трогать старую прошивку. Так ведь и нужно делать?

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

 

[_Desh_ 0]

В общем, решил я попробовать сделать все то же самое, только в 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.

Изменено 6 июня, 2012 пользователем _Desh_

[StewartLittle 41]

А я, следуя инструкциям Альтеры, пытался прошить .elf в уже работающее устройство. Может, дело в этом?

Нет, не в этом.

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

[_Desh_ 0]

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

Изменено 8 июня, 2012 пользователем _Desh_

[Wic 0]

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

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

[Копейкин 0]

Такие фокусы, как невозможность прочесть system ID и timestamp, очень часто случается, когда не

работает или не соответствует ожидаемым параметрам тактовый генератор.

Я, запаяв не рабочий генератор, тоже как-то долго пытался дебажить проект, и тоже не верифицировалась залитая

программа, не совпадал сисид и время создания...

1) Проверьте, на те ли выводы подаётся тактовая частота и работает ли генератор?

2) Проверьте назначение пина для тактовой частоты в проекте.

3) Есть возможность проверить другую плату/рабочий проект?

 

PS

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

Мне сюрпризов почти не преподносила.

Изменено 8 июня, 2012 пользователем Копейкин

[_Desh_ 0]

1) Проверьте, на те ли выводы подаётся тактовая частота и работает ли генератор?

2) Проверьте назначение пина для тактовой частоты в проекте.

3) Есть возможность проверить другую плату/рабочий проект?

 

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

 

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

[Wic 0]

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

[Копейкин 0]

Desh, я работаю с версией 9.1 SP 2 и у меня глюков мало.

Eclipse работает вполне стабильно.

Изредка отваливается/не стартует консоль Nios, но при следующем запуске, как правило всё ОК.

[Reanimatorr 0]

Небольшой вопрос-уточнение,

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

 

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

 

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

 

Все ли верно?

[_Desh_ 0]

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