Привет всем! Прошу помощи!
Сделал проект Cyclone EP1C12, EPCS16, память программы - SDRAM. Пока размер программы был небольшой, проблем не возникало т.е программу отлаживал чераз JTAG и грузил в EPCS. Различий в выполнении программы по JTAG и из EPCS по включению питания не наблюдалось. Программа увеличилась в размерах, в итоге был получен вариант, нормально работающий при загрузке через JTAG (т.е. из квартуса грузил sof - файл, из эклипса - программу для ниоса). После прошивки EPCS16 и передергивания питания проект работает, но наблюдаются баги. При повторной загрузки программы для ниоса через эклипс - все ок. Баги связанны с пересылкой пакетов через ethernet. Версия квартуса 9.0 (при установке sp2 - результат тотже). Не понятно в какую сторону "копать": то ли это некорректный программный код или проект для квартуса, то ли неадекватная запись/чтение из/в EPCS? ЧИтал дамп EPCS, но не смог сравнить с исходным (размер слитого флеш файла ~4.8Мб, а исходного ~270Кб). Как понять адекватность загрузки в EPCS через flash programmer.
И еще одно: при программировании через flash programmer получен следущий лог (привожу часть)

# Creating .flash file for the FPGA configuration
"$SOPC_KIT_NIOS2/bin/sof2flash" --epcs --input="xxx.sof" --output="xxx.flash"
Info: *******************************************************************
Info: Running Quartus II Convert_programming_file
Info: Command: quartus_cpf --no_banner --convert --device=EPCS128 --option=xxx
.opt xxx.sof xxx.pof

Почему EPCS128?

Будут у кого какие соображения?

зашить флеш:
nios2-flash-programmer --epcs --base=адрес имя_файла.flash
проверить флеш:
nios2-flash-programmer --verify --epcs --base=адрес имя_файла.flash

EPCS128 - при конвертации берется с запасом, это нормально

лог после nios2-flash-programmer --verify --epcs --base=адрес имя_файла.flash

Using cable "USB-Blaster [USB-0]", device 1, instance 0x00
Restetting and pausing target processor: OK
Verified 91KB in 2.6s <35 KB/s>
Leaving target processor paused

Как я понимаю все нормально !? До этого я пытался сливать файл командой nios2-flash-programmer --read и сравнивать файлы по содержимому. Ничего не получалось.
Как тогда могут по разному работать проекты из EPCS и через JTAG?
Ещё вопрос по максимальному размеру программы для НИОСа, кот. можно загрузить в EPCS16. EPCS16 имеет размер памяти 16777216 бит, EP1C12 имеет максимальный размер загрузочного файла - 2323249 бит, т.е для программы ниоса остается 14453967 бит (~ 1.7МБ). Это теоретически, а как практически?

А винда какая?

XP SP3 32bit

например: времянки, фокусы с кэшем.

так и есть. еще сжатие для конф. файла включить.

А что за девайс у тебя, самодельный или может отладочная плата какаято? У меня была подобная проблема, вот ссылка на тему на этом форуме
нестабильная загрузка nios
Там оказалась проблема с платой, помехи по питанию убрали и все стало нормально

Плата самодельная, ещё с теми извратами не по моей вине.
В том то и дело что у меня всё стабильно. Стабильно через JTAG работает как надо, и стабильно из EPCS работает не верно. Неправильность заключается в том, что обмен пакетами через Ethernet прекращается стабильно с 3-й попытки. Т.е. если бы при переедёргивании питания каждый раз было бы по-разному, грешил бы на питание.

воткните в систему jtag-uart, в опасных местах (типа while (какой-то флаг взведен)) наставьте printf, локализуйте баг. самописных компонентов нет?

Под времянками понимается Fmax после разводки (здесь всё вроде нормально) и констрейны для SDRAM (здесь нет 100% понимания, но я всегда пытался "грешить" на SDRAM, но ни разу не нашёл подтверждения этому, тесты SDRAM проходили, были попытки "зацепится" за что то путём тупой переразводки в Квартусе после незначительных изменений в проекте, переразводка ни на что не и разу не повлияла.)?
Про фокусы с кэшем можно подробней?



так когда с EPCS гружу как JTAG (printf) использовать?

Fmax сравнительно легко отследить, хуже если где-нибудь в протоколе обмена на таймаутах подвисает.

если в драйвере криво реализована работа с кэшем, пакеты будут приниматься неправильно. диагностировать сравнительно легко - отключить кэш данных и проверить.

а в чем проблема? главное, чтоб кабель подключен был. грузитесь с EPCS, а отладочную информацию кидаете по JTAG в nios2-terminal

Проблема решилась (скорее всего временно), путем создание своего Linker script'а на базе того, который генерируется автоматически (назначением нового диапазона адресов для секций памяти stack и heap). С увеличением объема программы глюки при передаче пакетов через ethernet повторились, но уже и при загрузке через JTAG. Начал исследовать то, как линкер создает "карту" памяти и нашел в nios2-gnutools утилиту nios2-elf-ld, которая выдала следующее (memorymap.png):

Нажмите для просмотра прикрепленного файла
а утилита nios2-elf-objdump (objdump.png):

Нажмите для просмотра прикрепленного файла

Каким образом можно избежать перекрытия секций памяти? и есть ли они в моем случае?