Коллеги, подскажите, в чем может быть дело.

Имеется плата со Spartan-6 и DDR MT41J128M16HA-125.
На основе Base system builder cоздал проект в EDK, экспортировал в SDK, сгенерировал программу с тестом памяти - работает.
Далее создаю программу Hello World, в linker script все секции прописываю в DDR - не работает.

Заранее благодарен.

А как она из флешки в ДДР попадет?
Загрузчик писать надо.
для тестов надо загрузить бутлуп в ПЛИС в микроблайз, А потом залить программу и стартануть из РАМа. Это если жетагом.

А автономный старт требует дополнительно загрузчика, который будет перепихивать программу из флеш в ддр

Согласен, но как я понимаю, для начала надо убедиться в том, что программа запускается через XMD.

для этого в SDK есть запуск проекта, сначала загружаете в ПЛИС bootloop - это автоматом создаваемый проект, можно в флеш прошить, можно просто грузить каждый раз
А потом вверху SDK есть иконка запустить или отладить. Через них запускаете проект из ДДР на запуск или на отладку

Когда я в SDK нажимаю на иконку "запустить", программа не запускается.

Предположение. Не помню как там у Xilinx, у альтеровского ниоса есть порт мастера данных и порт мастера инструкций. Когда ставишь on-chip ram, то оба этих порта на её слейв порт цепляешь и вектора процессора прописываешь на эту память. С векторами не в курсе, но если вы хотите секцию .text с собственно программой грузить с ddr, то проверьте, что у вас instruction master к ней подключен, может быть в этом дело.

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

А где можно про векторы почитать, ссылку не скинете?

У меня самого руки не доходили еще основательно изучить эти моменты. Там основная идея, что есть Reset Vector и Exception Vector. Вам наиболее инетересен первый, т.к. это тот адрес, с которого начинается бут сразу после резета. Можете покопать в эту сторону. Соответсвенно по этому адресу некий асембер, например, лежит, который дальше управление будет передавать.


а сигналы init_done, cal_success, cal_fail проверяете чип-скопом? Может у вас её что-то сбрасывает? Если для некоторых условий тетс памяти проходит, то сама память то целая.

Все это сейчас в EDK, и memory controller там как черный ящик. С левой стороны сигналы на микросхему, с правой - AXIS. Подозреваю, что init_done, cal_success, cal_fail - это некие внутренние сигналы. Если моя версия с ESR-конденсаторами не подтвердится, создам проект в ISE и буду тогда смотреть эти сигналы. Спасибо.

Вы используете контроллер памяти от Xilinx или сторонний? Контроллер должен выдавать на внутреннюю логику помимо AXIS дополнительный набор сигналов, как то: клоки со встроенного PLL, статусную шину и т.д. Перечисленные сигналы должны входить в статусную шину, просто у них возможно будет другое имя. В EDK можно разместить модуль чип скопа, если мне не изменяет память, и подключить его к этим сигналам. Просто эти сигналы первое, что следует проверять в случае проблем с DDR.

Я использую контроллер памяти от Xilinx.
Клоки от встроенного PLL действительного выдаются. Вы правы. Но статусной шины нет. Есть только uo_done_clk. Все остальное м.б. есть внутри, буду смотреть нетлист.

можно мониторить uo_done_cal и pll_locked, по ним уже можно что-то судить.

Сделайте в XPS очистку проекта и повторный экспорт в SDK. Возможно адресация в проекте изменилась и не передалась в SDK.
Когда память тестировали, адреса точно правильные были указаны? Именно DDR, а не внутренней памяти?

покажите картинку с шинами
как у вас шина инструкций и шина данных программ идут?

по поводу ДДР - ОЧЕНЬ!!! важно чтобы их контроллер питался от PLL в их регионе, просто через клок визард назначить клоки нельзя. Я налетел на это и время от времени процессор вис. Про это есть приписка в реф дизайне для ДДР, надо добавлять специальный констраин чтобы использвался верный PLL блок. Посмотрите пример любой с ддр вы увидите это констраин.

Про вектора вам это сейчас вообще не надо. Это все будет после загрузчика. Сейчас для этого bootloop есть он сделает как надо все. Загрузит проц и остановит его в ожидании прошивки для DDR. Попробуйте запустить проц на отладку, если у вас сбои DDR вы это увидите, как только делаете шаг на след инструкцию и она не наступает, то значит память грохнулась, останавливаете брейком и видите что вы черти где и память черти какая... или видит ошибку от жетага.

И еще если у вас в проце есть кеши, их надо инвалидейтнуть перед включением, лучше на первом этапе без них вообще. Это в свойствах проца настраивается.

В S6 ddr3 ввобще без проблем работает, когда создаёте проект визардом прямо в нём указываете ddr3, все настройки правильно визард делает. Потом можно поменять mcb блок на другой. Лучше всего проверить проект на ref плате типа SP605, если всё окей, то на своей. Разводка и пайка своей платы должна быть хорошей, тесты памяти только для младших адресов, они могут проходить, а программа не работать.

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



Сейчас к сожалению у меня нет борды 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.
Хотя все это очень странно, потому что я не помню, чтобы раньше (на другой плате) нужно было менять эту настройку. Все работало и так. Жалко, что нет платы отладки.

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