Все огромное спасибо за ответы.



Сейчас к сожалению у меня нет борды SP6, поэтому проверить не могу. Данный проект - это фактически проект, сгенеренный BSB (заменил ноги в UCF, поменял тактовую частоту). На старой работе проекты, сгенернные визардом, на бордах точно работали.
Что Вы имеет в виду под "Потом можно поменять mcb блок на другой"?

Про то, что "тесты памяти только для младших адресов, они могут проходить, а программа не работать." Я подкорректировал тест памяти. Проводится полная проверка, а не только младшие адреса.
ИМХО важная деталь: Если программу теста памяти объединить с bit-файлом через data2mem, то тест всегда проходит. Если программу теста памяти запустить через XMD, то он всегда виснет после печати начальных сообщений. Наверное, что-то не то со структурой EDK-проекта. Сейчас буду прикладывать скриншоты.

Конденсаторы поменял на Low-ESR - не помогло.










Подскажите, где можно посмотреть приписку? Вот UCF из refдизайна.





Я правильно понял, что надо на вкладке Cashe у МicroBlaze снять галки Enable Cashe? Если так, то MCB вообще остается отключенным.



Даже входа в отладку не происходит. Нельзя сделать даже первый шаг.




Понимаю, о чем Вы говорите, - EDK/SDK иногда подглючивает. Проект очистил, адреса проверил. Тестируются все 128 МБайт памяти, но только при условии, что сам тест запускается не из XMD, а из BRAM-ов.



uo_done_cal вывели на светодиод. Он НЕ светится.
C чипскопом небольшая проблема. В EDK, кажется, нужно system.ngc как-то преобразовывать, а потом уже грузить в chipscope. ngcbuild как то надо дополнительно запускать. У меня этот батник в другом корпусе .

pll_locked тоже не светится.
Т.е. все правильно, т.к. светодиоды на плате тянутся в VCC.

================================================================
А ВОТ СТОИТ ЗАПУСТИТЬ ТЕСТ ПАМЯТИ ИЗ-ПОД ОТЛАДЧИКА, И СИГНАЛ uo_done_cal ПАДАЕТ !!!
================================================================

Смотрите, что у вас сбрасывает память. Возможно вы туда резет каким-то образом ставите софтверно.

воот...

M_AXI_DC, M_AXI_IC - это шина данных и шина инструкций через кеш. Через нее можно получить данные только из кешируемой области.
1. Надо в настройках проца проверить что вся ваша DDR память входит в кешируемую область. Потому что иначе, если инструкция или данные для нее будут лежать в памяти не входящей в кешируемую область микроблайз полезет к ним через шины M_AXI_IP, M_AXI_DP а они у вас не подключены.
это в адванцед настройках микроблайза, в закладке кэш.
2. Если вы решите использовать кэш, то уже в SDK
надо вызывать его сброс перед включением, либо не включать на первых парах ваще


тесты памяти надо конечно без включенного кеша делать и программа должна запускаться из BRAM иначе она затрет саму себя когда будет память заполнять.






по клокам читайте UG388, это на контроллер памяти 2 раза тык тык, и внизу есть хелп к нему. ТАм есть 3 чаптер.

что-то я уже стал забывать точно где я прочел что нужен отдельный PLL, но где-то было. Без него под нагревом DDR начинало сбоить и плата начинала виснуть. Я добавлял всяких регистров на шины и прочее, это немного помогало, но радикально помогло завести клоки DDR от своего генератора, у меня в проекте их 2, один для проца и периферии, другой только для DDR. и вот такой констраин
INST "clock_generator_ddr/clock_generator_ddr/PLL0_INST/Using_PLL_ADV.PLL_ADV_inst" LOC = "PLL_ADV_X0Y1";
который зажимает на использование именно выбранный генератор.

Прикладываю скриншот настроек кеширования в microBlaze. У меня 128 мегабайт оперативы. Как я понимаю, настройки кэшь этому соответствуют. Мне непонятно, как вообще через XMD можно обращаться в DDR, если они находятся на разных AXI? М.б. их нужно как-то соединить? Или они уже где-то соединены?




Добавил эти строчки (в тест периферии, а не в тест памяти конечно). Похоже, программа вообще не запускается. Это видно из того, что когда запускаешь отладчик, то он пишет: No source available for "_start() "

да с кешем все ок.


XMD - это дебугер? А причем тут он?
к этим шинам имеет доступ процессор. Когда он обращается за следующей командой он смотрит ее адрес, если она в кешируемой области лезет в кеш, если в кеше команды нет, лезет в шину. С данными также, при чтении - записи.

Вы не забыли добавить дебуг информацию в настройках проекта в SDK?
как вы программу заливаете? точно по шагам напиши что делаете. Вот включили питание, дальше...?

1. Включаем питание.
2. Нажимаем кнопку Program FPGA. Выбираем там elf-файл программы теста памяти. Нажимаем кнопку Program.
3. Наблюдаем в COM-порт тест памяти:


4. Кликаем правой кнопкой по программе теста памяти (или по любой другой, будет то же самое). Далее Run As -> Launch on Hardware (GDB). В этот момент, как я понимаю, сегменты ELF-файла копируются в адресное пространство по тем адресам, которые указаны в linker script. Копирование выполняет программа XMD, ибо данный процесс копирования мы наблюдаем в XMD-console.

5. Мы хотим увидеть в COM-порт тест памяти, но

Ну тогда все правильно...
Проект из ДДР так не запустить, так можно запустить только проект из внутренних БРАМов.

ваша последовательность такая.
1. Включаем питание
2. нажимаем кнопку Programm FPGA и выбираем там elf файл который завется bootloop - это проект загрузчик
3. жмем кнопку Run, зеленый треугольник, в выпадющем меню ран конфиг, там задаем уже ваш боевой проект и его версию - это для запуска
3.1 жмем кнопку Debug жук рядом, все тоже самое для отладки.


Проект бутлуп придерживает фпга от работы на момент залитя прошивки в ДДР через ран. Без бутлупа, фпга несется по пустым брамам, и уходит в тупик, что вы и наблюдаете...

Через бутлуп тоже не работает.



Вы правы. Заработало !!!
Оказывается, надо было поставить "Reset processor only" in Run configuration. А там стояло Reset entire system.
Хотя все это очень странно, потому что я не помню, чтобы раньше (на другой плате) нужно было менять эту настройку. Все работало и так. Жалко, что нет платы отладки.

--
Всем признателен за ответы.