[dlsh 1]

Пытаюсь загрузить EP3C25 с помощью хоста (реализован на EP3C5 с ниосом). Примерно через 2к байт срабатывает nSTATUS как показано на рисунке. Данные передаются правильно (проверял КС сумму данных которые передает с ПК и тех что передаются в плис). Порядок младший бит первый. По всему выходит что плисина сбрасывает загрузку, но почему не понятно.

Может кто сталкивался с подобным, может еще какие пины посмотреть. В общем варианты что еще может быть пока закончилось.

[dlsh 1]

Что интересно, если я например записываю вместо данных все нули то nSTATUS остается в единице и данный эффект не проявляется, т.е. похоже что дело в данных...

[Koluchiy 0]

Я извиняюсь, но не могу не спросить.

До этого Вам уже доводилось грузить ПЛИСы вручную?

 

И еще вопрос.

С JTAG она нормально грузится?

[dlsh 1]

Я извиняюсь, но не могу не спросить.

До этого Вам уже доводилось грузить ПЛИСы вручную?

 

И еще вопрос.

С JTAG она нормально грузится?

 

Нет раньше не использовал, все больше активный с EPCS. Здесь нужно было пасивный по некоторым причинам, сам интерфейс ничего сложного, обычный SPI. Но вот статус начинает срабатывать на одном и том же месте как заколдованный. Пробовал разные проекты одно и тоже. Самое что интересно нет вообще никакого описания формата rbf. В общем куда копать пока не понятно.

Да с жтаг грузится нормально и после загрузки я вижу что conf_done поднимается.

Пробовал разные частоты от 0,5 МГц до 5 МГц результат один и тот же. Схемотехника все в норме.

[Koluchiy 0]

Проверьте, как начинается загрузка.

 

Если следовать букве AN116 (читаю версию, не знающую о Циклон 3, но не думаю, что чего-то сильно поменялось), то загрузка должна начинаться со сброса в 0, а потом возвращения в 1 сигнала nConfig с соответствующими временными ограничениями.

 

Кроме того, судя по времянке у Вас не реализован алгоритм рестарта загрузки, т.е. когда nStatus идет в 0, данные продолжают передаваться.

А после возвращения в 1 загрузка не перезапускается, или перезапускается неправильно.

 

Режим загрузки правильно выбран?

Изменено 13 июля, 2010 пользователем Koluchiy

[dlsh 1]

Проверьте, как начинается загрузка.

 

Если следовать букве AN116 (читаю версию, не знающую о Циклон 3, но не думаю, что чего-то сильно поменялось), то загрузка должна начинаться со сброса в 0, а потом возвращения в 1 сигнала nConfig с соответствующими временными ограничениями.

 

Кроме того, судя по времянке у Вас не реализован алгоритм рестарта загрузки, т.е. когда nStatus идет в 0, данные продолжают передаваться.

А после возвращения в 1 загрузка не перезапускается, или перезапускается неправильно.

 

Режим загрузки правильно выбран?

 

У меня загрузка начинается с поднятия nCONFIG в 1, ожидание когда nSTATUS = 1 и затем передача даных. Да после того как nSTATUS идет в 0 а затем в 1 я nCONFIG не трогаю, пробовал ожидать когда nSTATUS будет равен 1 и потом начинал загружать файл с начала, эфект тот же. Доходит до этого-же места и снова nSTATUS = 0 .. 1. Завтра попробую еще дернуть nCONFIG хотя в мануале сказано что в принципе это не обязательно типа это такой рестарт при какойто ошибки (возможные причины ошибок не указаны).

Режим загрузки MSEL[2 : 0] = 3'b0, тобишь PS norm.

В общем вилы.

Попробую ещё по управлять nCONFIG при изменении сигнала статуса, может и в этом дело....

[Koluchiy 0]

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

 

Вы уверены, что nConfig и nStatus до начала загрузки = 0?

Если нет, то приведение nConfig в 1 результата (фронт) не даст.

Поэтому во избежание я советую принудительно сначала в 1, ждать nStatus = 1, затем nConfig в 0 и т.д..

 

Кроме того, раз уж не работает, есть смысл отказаться от одной из ступеней, а именно от ПК.

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

 

Также выложите кусок схемы с конфигурационными и конфигурирующими ногами.

[aprox 0]

Вы не забыли, что байты последовательной загрузки в FPGA идут младшим битом вперед? А SPI хостов все больше норовят старшим битом вперед.

 

[ViKo 1]

Я для себя написал следующий алгоритм конфигурации. Правда, это для Cyclone-II, но, может, пригодится. Времена будут другие. Проверьте, что у вас удовлетворяются все условия - по времени, по напряжениям. Вдруг на тактовом сигнале глитчи?

 

* После включения питания Cyclone-II находится в состоянии сброса POR ~ 100 ms

* В это время ПЛИС удерживает STATUSn и CONF_DONE низким,

* а USER I/O в высокоимпедансном состоянии

* ПЛИС сбрасывается низким уровнем на любом из выводов CONFIGn или STATUSn

* Когда CONFIGn переводится из низкого уровня в высокий, сброс заканчивается

* и STATUSn переходит в высокоимпедансное состояние (через Max 40 us)

* Когда STATUSn отпущен, ПЛИС готова принять код конфигурации

* (фронт такта через min 1 us).

* VCCINT и VCCIO выводы должны быть запитаны требуемым напряжением.

* Код из памяти пересылается в ПЛИС побайтно, до тех пор пока ПЛИС не отпустит

* CONF_DONE, который за счет внешнего резистора станет высоким.

* Данные защелкиваются в ПЛИС по фронту / тактов (период min 10 ns).

* Первым посылается младший бит байта (LSB).

* Никакого сигнала BUSY не выдается (успевает записаться за 10 ns?).

* Такты DCLK после конфигурирования не влияют на ПЛИС.

* Для тактов инициализации можно задать использовать CLKUSR

* Или использовать внутренний тактовый генератор (~ 10 MHz) по-умолчанию

* Требуется 299 тактов, допускается частота до 100 MHz

* Такты CLKUSR не влияют на процесс конфигурации

* Сигнал INIT_DONE, если используется, говорит об окончании инициализации

* INIT_DONE становится низким после первого кадра конфигурации,

* и устанавливается высоким после инициализации

* После этого ПЛИС входит в USER режим

* В USER режиме внутренние weak pull-up резисторы на user I/O отключаются

* Если во время конфигурации случился сбой, STATUSn становится низким

* и ПЛИС сбрасывает себя внутри

* Для реконфигурации ПЛИС нужно подать низкий сигнал CONFIGn (min 40 us)

 

 

 

 

[dlsh 1]

Зугрузил прошивку во флэшку и с ней работаю. Все осталось по прежнему. Водрузил паралельно зашрузочному каналу spi slave и поставил проверку КС идущей на ep3c25, в общем данные идут верные даже при срабатывании nSTATUS КС остается равной КС переданной мастером.

Тайминги (ep3c25_timing) все выдержены.

Осталься вроде единственный вариант что то нето в схеме (прикрепил). Я вот думаю через ep3c25 пропущен жтаг от мастера ep3c5 может ли он вносить данную неприятность?

Перезагрузку пока не делал, вроде это бесмыслено т.к. старт идет правильный.

ep3c25_load__3.pdf

[dvladim 0]

Осталься вроде единственный вариант что то нето в схеме (прикрепил). Я вот думаю через ep3c25 пропущен жтаг от мастера ep3c5 может ли он вносить данную неприятность?

JTAG здесь ни при чем (хотя бросать его в воздухе нельзя).

Если не нарушали времянки, не попутали порядок бит в rbf, вообще конфигурационные потоки, то может быть такая хитрая штука: раз падает nSTATUS значит в конфигурационном потоке есть ошибка, но при этом начальный заголовок распознается. Возможно из-за отражения сигнала ПЛИС ловит лишние клоки. Попробуйте встать щупом осциллорафа на DCLK. Прямо на ногу ПЛИС или прикоснуться емкостью около 200 пФ. Если загрузится нормально то паяйте последовательно сопротивление на источнике DCLK. Или наоборот - при сильно заваленных фронтах может быть ложное срабатывание клока.

[dlsh 1]

Всем спасибо.

 

До чего неприятно, пол недели в трубу. Попутал DCLK и DATA. Ведь с самого начала проверил именно этого но как пропустил... вилы.

 

[aprox 0]

До чего неприятно, пол недели в трубу. Попутал DCLK и DATA. Ведь с самого начала проверил именно этого но как пропустил... вилы.

"Электроника- это наука о контактах."