Всем привет! Есть некое изделие в состав которого входит FPGA EP3C120 с ниос , синтезатор частоты ADF5355 и много других разностей. Но проблема с загрузкой синтезатора. Программа в ниос написана так : в файле инициализации читается код нужной частоты из EPCS и на эту частоту программируется синтезатор. Далее по Ethernet ниос может получить команду на изменение частоты синтезатора и перепрограммирует синтезатор с записью новой частоты в EPCS. Так вот не удаётся получить запрограммированный синтезатор после включения питания, т.е. выполнить загрузку синтезатора из процедуры инициализации. Причём команды по Ethernet выполняются без нареканий. Провозился вчера целый день а воз и ныне там. Перепробовал всё что приходило в голову : увеличивал задержки, загрузчику подсовывал частоту в виде константы и многое другое. Если запуститься в режиме отладки и поставить точку останова после загрузки синтезатора то на выходе получаю нужную частоту,всё работает. Бред какой-то... Проблема осложняется тем что так произошло что эта работа выполняется дистанционно(блок в другом городе). Анализатор спектра и осциллограф тоже не вариант. Но т.к. управление по сети выполняется предполагаю что с самим синтезатором всё нормально. Буду рад услышать любые предположения.

ИМХО где-то времянки не соблюдаются. Когда из-под отладчика стартует - всё чуть медленнее исполняется, а когда из пзушки - быстрее. Проверить бы зависимые от интервалов времени вещи (тот же SPI, например...).
В качестве диагностики я бы взял USB-шный логгер и снял диаграммы прогрузки синтезатора в обоих случаях - из под отладчика и без него.

Спассибо! SPI аппаратный в FPGA, от ниос не зависит. Команды выполняются без отладчика...

Бывает ещё зависимые от конкретного чипа фишки типа "прогрузить вот этот регистр, потом подождать не менее 10мС и проверить такой-то бит".

Да,есть такие нюансы но тактовая ниос вроде не меняется. После подачи питания я делаю задержку 500мс , потом инициализацию. Или я не том?

А значение в памяти точно меняется?

А почему бы вместо Nios с его богатым внутренним миром не обойтись ясным и простым самописным конечным автоматом?

Стек сетевых протоколов на автомате? Я не мазохист.

1. Речь про замену Nios Core на автомат, а не про написание стека сетевых протоколов.
2. Оный стек не является чем-то исключительным и связанным именно с Nios.

Я ж не спорю. Но причину я назвал.

По-моему, здесь два взаимоисключающих утверждения, но вам виднее.

Инициализация самого ADF5355 правильно сделана? Ему надо все регистры прописать сначала.
Возможно и каких то LOCK'ов дождаться (надо DS читать вдумчиво)

Поставьте софт (http://www.analog.com/media/en/evaluation-boards-kits/evaluation-software/ADF4355_v1_0_10.zip) - из него можно извлечь правильную последовательность инициализации и установки частоты

Дополнительная информация : поставил в фоне вот такой кусок:

При работе из ПЗУ примерно раз в две секунды перезагружаю синтезатор - никакого эффекта. А при работе из отладчика при этой самой вставке сигнал на выходе есть. По моему это полная шизофрения - ну не может такого быть!


О,только сейчас увидел Ваше сообщение,спасибо!
Сейчас глянем.

Ну так я и делаю - от старших к младшим регистрам. Только у них там не всё, для калибровки отдельная процедура нужна, в ds есть.

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

Топикстартеру, т.е. вы хотите сказать, что если тупо прошьёте EPCS jtag-ом c новыми данными для синтезатора, то ничего не отработает?

Да,всё так и есть. Даже если частоту указываю явно (FreqExternalRfMod = FREQ_DEFAULT_TR;)Причём управление по Ethernet позволяет менять частоту синтезатора.

А с опорой всё нормально у него?
У нас он не лочился пока печка OCXO не прогреется - т.к. там калибровка ГУНа идёт при перестройке частоты. Чуть-что не так - ГУН не правильно откалибровывается и светодиод не горит.

1. В данном случае костылем считаю именно Nios.
2. Суть с большой долей вероятности именно в неверном использовании особенностей Nios-корки.
3. Разбираться в чужих корках, имея возможность дешевого решения, считаю контропродуктивным.
3. Управляющая логика, описанная ТС, довольно проста и реализуется за считанные часы с помощью автомата.
4. Темы, посвященные борьбе с настройками IP-корок возникают с завидной регулярностью (с точностью до совпадения авторов тредов), что лишний раз укрепляет меня в выводах относительно наиболее простых и дешевых методов разработки ПО для ПЛИС.


1. Сильно сомневаюсь.
2. Цена реализации этого варианта несущественна по сравнению с уже затраченным временем.

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

Реализовать на автомате IP стек за считанные часы?

Вы серьезно ?

Тему читайте внимательно и таких вопросов не будет.
https://electronix.ru/forum/index.php?showt...t&p=1462537



За свой счет серьезно, а за чужой готов поприкалываться.