Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Altera Remote Ststem Update
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
doom13
Добрый день.
В проекте присутствует ядро Remote update, всё управление происходит с помощью Nios II. Есть две конфигурации: factory и application.
Factory заливается по адресам 0x0, application - 0xd00000. Включается питание запускается factory конфигурация, которая через Remote Update загружает конфигурацию application.
Алгоритм работы для factory следующий:
Код
rd_data = rsu_controller_rd_reconf_src_condition((void *)RSU_CONTROLLER_BASE);
if((rd_data == RECONF_SOURCE_POR) || (rd_data == RECONF_SOURCE_EXTERNAL_RST) || (rd_data == RECONF_SOURCE_LOGIC_TRIGGERED))
{
    rsu_controller_wr_config_mode((void *)RSU_CONTROLLER_BASE, CONFIG_MODE_APPLICATION);
    rsu_controller_wr_wdt_timeout((void *)RSU_CONTROLLER_BASE, RSU_WDT_TIMEOUT_VALUE);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_WDT_ENABLE, 1);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_PAGE_SELECT, APPLICATION_PAGE_START_ADDRESS);
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
}


Алгоритм работы для application:
Код
rd_data = rsu_controller_rd_config_mode((void *)RSU_CONTROLLER_BASE);
if(rd_data == CONFIG_MODE_APPLICATION)
{
    rd_data = rsu_controller_read_param((void *)RSU_CONTROLLER_BASE, PARAM_WDT_ENABLE);
    if(rd_data)
    {
         rsu_controller_reset_timer((void *)RSU_CONTROLLER_BASE, 1); // сигнал разрешения сброса wdt, разрешает подачу меандра на вход reset_timer ядра Remote Update
    }
}


Для удобства перепрошивки довавлена функция реконфигурации, алгоритм которой:
Код
#if __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_FACTORY
    rsu_controller_wr_config_mode((void *)RSU_CONTROLLER_BASE, CONFIG_MODE_FACTORY);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_WDT_ENABLE, 0);
    rsu_controller_wr_wdt_timeout((void *)RSU_CONTROLLER_BASE, 0);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_PAGE_SELECT, FACTORY_PAGE_START_ADDRESS);
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
#elif __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_APPLICATION
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
#endif


Вопросы в следующем:
1) Заливаем factory, application, переключаем питание - всё работает, даём команду Reconfig - всё перезапускается.
2) Залит только factory. По включению питания запустилось, дали команду Reconfig - всё ок.
3) Проблемная ситуация 1: Находимся в режиме application и перезаливаем прошивку для application. Что-то легло - прошивка залилась неправильно/частично, даём команду Reconfig и FPGA уже не стартует (а должна была остаться конфигурация factory).
Сбрасываем питание, запускается factory и Reconfig для него уже работает.
4) Проблемная ситуация 2: Включаем питание. Для application залита какая-то ерунда - загружается конфигурация factory. Factory перезаливает прошивку для application, делаем Reconfig и всё опять дохнет (а должна была стартануть конфигурация application). По сбросу питания опять всё запускается, переходит в режим application и нормально работает.
vadimuzzz
посмотрел у себя в коде, все аналогично. возникли вопросы: 1) почему в factory не рассматривается как источник сброса wdt, 2) почему wdt отключен в функции реконфигурации?
doom13
Цитата(vadimuzzz @ Jan 23 2015, 07:08) *
посмотрел у себя в коде, все аналогично. возникли вопросы: 1) почему в factory не рассматривается как источник сброса wdt?

Предполагаю, что factory надёжная (рабочая) конфигурация, а в ней я могу просто отключать wdt (в application такой возможности нет - использую сброс).

Цитата(vadimuzzz @ Jan 23 2015, 07:08) *
2) почему wdt отключен в функции реконфигурации?

Это он отключён во втором варианте работы, где перезагрузка должна произойти с адресов factory. Изначально было так:
Код
#if __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_FACTORY
    rsu_controller_wr_config_mode((void *)RSU_CONTROLLER_BASE, CONFIG_MODE_APPLICATION);
    rsu_controller_wr_wdt_timeout((void *)RSU_CONTROLLER_BASE, RSU_WDT_TIMEOUT_VALUE);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_WDT_ENABLE, 1);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_PAGE_SELECT, APPLICATION_PAGE_START_ADDRESS);
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
#elif __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_APPLICATION
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
#endif

Но оба варианта не работают.
vadimuzzz
Цитата(doom13 @ Jan 23 2015, 12:38) *
Предполагаю, что factory надёжная (рабочая) конфигурация, а в ней я могу просто отключать wdt (в application такой возможности нет - использую сброс).

но если app-прошивка сбойная, то wdt вернет к factory. если же вы не включите wdt, то после перехода в application со сбойной прошивкой, ПЛИС повиснет. вот мне и непоятно - откуда 2 варианта функции реконфигурации для factory?
doom13
С Ваших слов возникло предположение по поводу необходимости сброса wdt для factory. Счас буду пробовать.
Цитата(vadimuzzz @ Jan 23 2015, 09:56) *
но если app-прошивка сбойная, то wdt вернет к factory. если же вы не включите wdt, то после перехода в application со сбойной прошивкой, ПЛИС повиснет. вот мне и непоятно - откуда 2 варианта функции реконфигурации для factory?

По поводу вариантов реконфигурации. Сначала пробовал для factory перенаправлять на application, а потом ещё было предположение перезагружать сам factory который уже и будет стартовать application (эти переходы только если всё запустилось и даём команду на реконфигурацию - внешняя команда).

UPP:
Но как тогда работает пункт №2 (залит factory и кривой application)? Включаю питание, а он остаётся в режиме factory. Или после переполнения wdt он сбросит FPGA (в factory) и далее остановится? Ведь если он не остановится, то в данном случае должен быть постоянный реконфиг (factory не сбрасывает wdt).
vadimuzzz
Цитата
UPP:
Но как тогда работает пункт №2 (залит factory и кривой application)? Включаю питание, а он остаётся в режиме factory. Или после переполнения wdt он сбросит FPGA (в factory) и далее остановится? Ведь если он не остановится, то в данном случае должен быть постоянный реконфиг (factory не сбрасывает wdt).

я так понимаю собственно в factory он не нужен: wdt включается только перед попыткой загрузки application. кстати, мне кажется, что переписывать factory не стоит в принципе. т.к. если что-то отвалится при обновлении, вернуться будет не к чему.
doom13
Цитата(vadimuzzz @ Jan 23 2015, 11:06) *
я так понимаю собственно в factory он не нужен: wdt включается только перед попыткой загрузки application. кстати, мне кажется, что переписывать factory не стоит в принципе. т.к. если что-то отвалится при обновлении, вернуться будет не к чему.

Так вот и получаем, что при переходе на application wdt всегда включен (код для factory - всё включено и делаем переход; функция реконфигурации (вариант с переходом на адреса application) - так же всё включено).
Переделал немного код. Старт программы:
Код
#if __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_FACTORY

    rsu_controller_reset_timer((void *)RSU_CONTROLLER_BASE, 1); // разрешение периодического сброса wdt

    rd_data = rsu_controller_rd_reconf_src_condition((void *)RSU_CONTROLLER_BASE);
    if((rd_data == RECONF_SOURCE_POR) || (rd_data == RECONF_SOURCE_EXTERNAL_RST) || (rd_data == RECONF_SOURCE_LOGIC_TRIGGERED))
    {
        rsu_controller_wr_config_mode((void *)RSU_CONTROLLER_BASE, CONFIG_MODE_APPLICATION);
        rsu_controller_wr_wdt_timeout((void *)RSU_CONTROLLER_BASE, RSU_WDT_TIMEOUT_VALUE);
        rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_WDT_ENABLE, 1);
        rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_PAGE_SELECT, APPLICATION_PAGE_START_ADDRESS);
        rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
    }

#elif __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_APPLICATION

    rsu_controller_reset_timer((void *)RSU_CONTROLLER_BASE, 1); // разрешение периодического сброса wdt

#endif


Функция реконфигурации:
Код
#if __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_FACTORY
    rsu_controller_wr_config_mode((void *)RSU_CONTROLLER_BASE, CONFIG_MODE_APPLICATION);
    rsu_controller_wr_wdt_timeout((void *)RSU_CONTROLLER_BASE, RSU_WDT_TIMEOUT_VALUE);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_WDT_ENABLE, 1);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_PAGE_SELECT, APPLICATION_PAGE_START_ADDRESS);
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
#elif __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_APPLICATION
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
#endif

Результат тот же. По включению питания работает всегда (не зависит от наличия и корректности application, т.е. либо загрузит application, либо останется в factory). Если был залит битый application, a factory перезаливает новый правильный application во флэш и пытается его стартануть, то всё виснет. Если всё стартануло, application пишет во флэш битый application а потом переходит на factory, чтобы перезапустить новую прошитую прошивку, - всё повиснет.

Ещё накопал вот это, но не могу понять относится оно или нет к моему случаю.
vadimuzzz
Цитата(doom13 @ Jan 23 2015, 14:30) *
Ещё накопал вот это, но не могу понять относится оно или нет к моему случаю.

если это оно, должна дергаться нога nSTATUS
doom13
Цитата(vadimuzzz @ Jan 23 2015, 12:00) *
если это оно, должна дергаться нога nSTATUS


Для обоих ситуаций
Цитата
Если был залит битый application, a factory перезаливает новый правильный application во флэш и пытается его стартануть, то всё виснет. Если всё стартануло, application пишет во флэш битый application а потом переходит на factory, чтобы перезапустить новую прошитую прошивку, - всё повиснет.

nSTATUS дёргается (после сброса питания всё восстанавливается). Что думать, что это их баг, пытаться задействовать pof checking? Но ситуация отлична от описанной в указанных доках, одинаково только поведение nSTATUS.

UPP: из их доки понял, что без pof checking вообще ничего работать не должно?!
vadimuzzz
Цитата(doom13 @ Jan 23 2015, 15:22) *
nSTATUS дёргается (после сброса питания всё восстанавливается). Что думать, что это их баг, пытаться задействовать pof checking? Но ситуация отлична от описанной в указанных доках, одинаково только поведение nSTATUS.

хз, но проверить стоит
doom13
Нашёл ещё одну глючную ситуацию, работает application (работа начиналась с включения питания factory запускал application) и посылается новая прошивка для application (прошивка правильная). Прошивка записывается во флэш. После перепрошивки конфигурационной флэшки пытаюсь сделать RECONFIG, а оно опять дохнет. После переключения питания возобновляет работу. Т.е. получается, что RECONFIG не работает именно после перепрошивки конфигурационной флэшки (для описанных выше ситуаций везде присутствовала перезапись флэша!!!).
Если перезаписи флэша не было. Выполняем RECONFIG для factory с битым application, то работает правильно - остаётся в factory. Если выполнять RECONFIG для аpplication (без записи флэшки), так же работает - сбрасывается на factory, который опять же запустит application.
Очень похоже на какую-то проблему с интерфейсом конфигурационной флэшки. Для прошивки используется EPCS/EPCQx1 flash controller, может быть проблема в нём, что-то не могут поделить c Remote Update?
vadimuzzz
Цитата(doom13 @ Jan 23 2015, 16:51) *
Очень похоже на какую-то проблему с интерфейсом конфигурационной флэшки. Для прошивки используется EPCS/EPCQx1 flash controller, может быть проблема в нём, что-то не могут поделить c Remote Update?

а сигналы с/на флешку идут, когда nSTATUS дергается?
doom13
Цитата(vadimuzzz @ Jan 23 2015, 14:35) *
а сигналы с/на флешку идут, когда nSTATUS дергается?

Да идут.
Golikov A.
может сократить пути и уменьшить число вариантов загрузок или задача решить именно в таком раскладе?
doom13
Цитата(Golikov A. @ Jan 23 2015, 15:06) *
может сократить пути и уменьшить число вариантов загрузок или задача решить именно в таком раскладе?

Задача сделать две прошивки в конфигурационной флэшке (нестираемый или стираемый c запросом прав доступа factory и стираемый при обновлении ПО application).
Golikov A.
просто можно грузиться всегда через фактори и она принимает решения грузить апликайшен или нет (целостность, кнопка, специальный флаг, коды защиты)
фактори сделать не убиваемой и не стираемой

Обновление всегда через перезагрузку и остановкой в фактори для обновления апликейшена, и старт опять через перезагрузку.
Так вы получите всегда стандартное начало, которое не надо будет проверять на комбинации.

вот обновление фактори я обычно не делаю, и если уж прижмет делаю его жетагом или внешним программатором напрямую в память, слишком уж большой шанс если что не так кирпич на выходе получить... а у клиента всегда все не так идет...
doom13
Цитата(Golikov A. @ Jan 23 2015, 20:47) *
просто можно грузиться всегда через фактори и она принимает решения грузить апликайшен или нет (целостность, кнопка, специальный флаг, коды защиты)
фактори сделать не убиваемой и не стираемой

Обновление всегда через перезагрузку и остановкой в фактори для обновления апликейшена, и старт опять через перезагрузку.
Так вы получите всегда стандартное начало, которое не надо будет проверять на комбинации.

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

Всё так, только вот проблема в том, что после перепрошивки флэша не получается перезагрузить обновлённую конфигурацию программно (а должно работать). Стартанёт только после сброса питания. И перезапуск (программный) работает, если флэш на запись не трогать.
Golikov A.
а вочьдогом перегрузить?
doom13
Цитата(Golikov A. @ Jan 24 2015, 00:49) *
а вочьдогом перегрузить?

Думаю, результат будет тот же, т.к. меняем только источник реконфигурации: была ножка ядра reconfig, а предлагаете wdt. Да и это попытка обойти то, что не работает, а не устранение самой причины проблемной ситуации. Reconfig прекрасно работает и для factory и для application, если флэшку не трогали. Вот в этом и хочу разобраться, каким образом работа EPCS/EPCQx1 Controller-a влияен на модуль Remote Update.
doom13
Почитал ещё параметры для Remote Update, после старта FPGA, получаю следующее.
1) Залит только factory. По включению питания он запускается настраивает WDT и пытается стартануть application (которого нет), как результат опять перезагружается factory.
Читаем Reconfiguration trigger conditions - получаем 02h (ожидалось 10h - сброс от wdt).
2) Залит factory и битый application (начало application). По включению питания запускается factory настраивает WDT и пытается стартануть application (который битый), как результат опять перезагружается factory. Читаем Reconfiguration trigger conditions - получаем 01h (ожидалось 10h - сброс от wdt).
3) Залит factory и application - тут всё понятно, при чтении Reconfiguration trigger conditions получаем 04h - сброс от логики.

Каким образом получаются такие значения Reconfiguration trigger conditions для случаев 1 и 2?
doom13
Как и предполагалось, есть какая-то ерунда при использовании EPCS/EPCQx1 Flash Controller-a вместе с Remote Update. Если для общения с EPCQ использовать ASMI, описанной выше проблемы не наблюдается - команда RECONFIG работает после записи флэша.

???
vadimuzzz
Цитата
Как и предполагалось, есть какая-то ерунда при использовании EPCS/EPCQx1 Flash Controller-a вместе с Remote Update. Если для общения с EPCQ использовать ASMI, описанной выше проблемы не наблюдается - команда RECONFIG работает после записи флэша.

а какая версия квартуса? вроде в 13 или 13.1 был баг то ли программера, то ли бутлодера
doom13
Цитата(vadimuzzz @ Jan 27 2015, 05:44) *
а какая версия квартуса? вроде в 13 или 13.1 был баг то ли программера, то ли бутлодера

Версия Q14.0 и девайс 5cefa9. Там баг с Nios II Flash Programmer, он и в этой версии не работает, но какое он к данной проблеме может иметь отношение, я-то не им прошивку обновляю?
vadimuzzz
Цитата(doom13 @ Jan 27 2015, 12:11) *
Там баг с Nios II Flash Programmer, он и в этой версии не работает, но какое он к данной проблеме может иметь отношение, я-то не им прошивку обновляю?

может баг не в нем (или не только в нем). ASMI от EPCQ только количеством проводов данных отличается?
doom13
Цитата(vadimuzzz @ Jan 27 2015, 12:09) *
может баг не в нем (или не только в нем). ASMI от EPCQ только количеством проводов данных отличается?

Не понял вопрос. EPCS/EPCQx1 Flash Controller под NIOS заточен (на Avalon-e висит и разрядность там 32, внутренности не смотрел), а ASMI (Active Serial Memory Interface) позволяет всё то же, но это чисто железный блок (данные 8-миразрядные), чтоб его к Nios прикрутить - свой контроллер набросал и драйвера для работы с ним.

Посмотрел на драйвера для EPCS/EPCQx1 Flash Controller, запись там по 8 бит реализована (обычный spi).
vadimuzzz
Цитата(doom13 @ Jan 27 2015, 16:40) *
Не понял вопрос. EPCS/EPCQx1 Flash Controller под NIOS заточен (на Avalon-e висит и разрядность там 32, внутренности не смотрел), а ASMI (Active Serial Memory Interface) позволяет всё то же, но это чисто железный блок (данные 8-миразрядные), чтоб его к Nios прикрутить - свой контроллер набросал и драйвера для работы с ним.

контроллер EPCQ в ниосе поддерживает режим x4? ASMI-то его точно не поддерживает
doom13
Цитата(vadimuzzz @ Jan 28 2015, 07:55) *
контроллер EPCQ в ниосе поддерживает режим x4? ASMI-то его точно не поддерживает

Да нет, ASMI умеет работать в режиме х4 (выбирается тип флэша - epcq). Проверено осциллом - сигнал при прошивке ASMI есть на всех линиях данных DQ0, DQ1, DQ2, DQ3. А вот EPCS/EPCQx1 Flash Controller поддерживает, как понимаю, только режим х1 (судя по названию ядра). При прошивке флэша EPCS/EPCQx1 Flash Controller-ом сигнал есть только на DQ0 (serial data input) и DQ1 (serial data output)).
vadimuzzz
Цитата(doom13 @ Jan 28 2015, 14:12) *
Да нет, ASMI умеет работать в режиме х4 (выбирается тип флэша - epcq). Проверено осциллом - сигнал при прошивке ASMI есть на всех линиях данных DQ0, DQ1, DQ2, DQ3. А вот EPCS/EPCQx1 Flash Controller поддерживает, как понимаю, только режим х1 (судя по названию ядра). При прошивке флэша EPCS/EPCQx1 Flash Controller-ом сигнал есть только на DQ0 (serial data input) и DQ1 (serial data output)).

а в момент, когда начинает reconfig глючить (когда nSTATUS дергается) какие/сколько линии данных(DQ) активны?
doom13
Цитата(vadimuzzz @ Jan 28 2015, 11:41) *
а в момент, когда начинает reconfig глючить (когда nSTATUS дергается) какие/сколько линии данных(DQ) активны?

Отличие только в DQ0. Для случая, когда RECONFIG работает - она '0' (не было перезаписи epcq), для случая - RECONFIG не работает она '1' (была запись epcq и DQ0 осталась в '1').
Golikov A.
а флешка не переконфигурируется на чтение по 1 или 4 линиям? может в каком-то режиме она всегда читается по одному, без переконфигурации?
doom13
Цитата(Golikov A. @ Jan 28 2015, 12:08) *
а флешка не переконфигурируется на чтение по 1 или 4 линиям? может в каком-то режиме она всегда читается по одному, без переконфигурации?

Данная флэш-память может работать в обоих режимах, но делo не в самой памяти, проблема с её контроллером, а это уже IP-ядро от Altera.
vadimuzzz
Цитата(doom13 @ Jan 28 2015, 15:26) *
Данная флэш-память может работать в обоих режимах, но делo не в самой памяти, проблема с её контроллером, а это уже IP-ядро от Altera.

я это и имел в виду: м.б. при реконфиге через EPCQx1 плис пытается по 4-м линиям читать, а память по одной выдает?
doom13
Цитата(vadimuzzz @ Jan 28 2015, 12:57) *
я это и имел в виду: м.б. при реконфиге через EPCQx1 плис пытается по 4-м линиям читать, а память по одной выдает?

Если правильно понимаю, то режим загрузки (х4) задаётся прошивкой (в начале есть инфа, как настроить интерфейс загрузки). Если перекомпилить на х1, то бинарник отличается.

Вот это Вы не пропустили:
Цитата(vadimuzzz @ Jan 28 2015, 11:41) *
а в момент, когда начинает reconfig глючить (когда nSTATUS дергается) какие/сколько линии данных(DQ) активны?
Цитата(doom13 @ Jan 28 2015, 12:07) *

Отличие только в DQ0. Для случая, когда RECONFIG работает - она '0' (не было перезаписи epcq), для случая - RECONFIG не работает она '1' (была запись epcq и DQ0 осталась в '1').

???
Или это - подтверждение.
Golikov A.
ну пока прошивку не считаешь, режим же не поймешь. Потому изначально флешка должна в каком-то одном виде отвечать в дефолтном. После обращения настраивается режим, какой-то конкретно заданный. И вот вопрос перенастривается ли - сбрасывается ли он перед обращением уже после обновления...
vadimuzzz
Цитата(doom13 @ Jan 28 2015, 16:05) *
Или это - подтверждение.

не совсем: по линии dq0 во всех режимах передаются опкоды. что если ситуация примерно такая: контроллер дает опкод на чтение по 4-м линиям, а физически к корке подключена одна? и еще, в даташите на epcq есть раздел про "Non-Volatile Configuration Register", драйвер ничего с ним не делает?
doom13
Цитата(vadimuzzz @ Jan 28 2015, 14:01) *
не совсем: по линии dq0 во всех режимах передаются опкоды. что если ситуация примерно такая: контроллер дает опкод на чтение по 4-м линиям, а физически к корке подключена одна? и еще, в даташите на epcq есть раздел про "Non-Volatile Configuration Register", драйвер ничего с ним не делает?

Проблема есть с EPCS/EPCQx1 Controller-ом, про него и пишу: я использую только ф-ии alt_epcs_flash_init(), alt_epcs_flash_erase_block(), alt_epcs_flash_write_block() из папки с драйверами, а как они реализованы - не вникал. Явно никакие настройки для флэшки в этих функциях не задаются.
doom13
Default-mode для EPCQ256 (N25Q256) - это, как понимаю, х1. Т.е. при загрузке ПЛИС должна перевести её в х4, а потом грузится (по окончании загрузки вернуть режим в х1).
EPCS/EPCQx1 controller работает в режиме х1. Далее Remote Update задаёт реконфигурацию и загрузчик должен залить обновлённую прошивку перенастроив х1 в х4, но почему-то не может.

Стёр флэшку, при включении питания активны DQ0 (serial data input) и DQ1 (serial data output) - FPGA пробует считать прошивку. На DQ2, DQ3 - '1' (вижу высокий уровень). В случае обновления прошивки и выполнения RECONFIG все пины активны (FPGA читает в режиме х4).
vadimuzzz
Цитата(doom13 @ Jan 28 2015, 19:04) *
EPCS/EPCQx1 controller работает в режиме х1. Далее Remote Update задаёт реконфигурацию и загрузчик должен залить обновлённую прошивку перенастроив х1 в х4, но почему-то не может.

до загрузчика, я так понимаю, дело просто не доходит - он запускается уже в user-mode. а есть возможность все операции, включаяя загрузку sof, выполнить в режиме x1? если получится, значит действительно что-то с переключением режимов флешки
doom13
Цитата(vadimuzzz @ Jan 28 2015, 17:10) *
до загрузчика, я так понимаю, дело просто не доходит - он запускается уже в user-mode. а есть возможность все операции, включаяя загрузку sof, выполнить в режиме x1? если получится, значит действительно что-то с переключением режимов флешки

А вот с загрузкой прошивки сконвертированной для Active Serial есть какой-то баг, не стартует с ней FPGA.
Может быть это из-за того, что в настройках проекта (Device and Pin Options->Configuration->Configuration scheme) у меня выбран Active Serial x4, а сконвертить пытаюсь для Active Serial?
Или выбранный в настройках Active Serial x4 на генерацию sof влиять не должен?
doom13
Перекомпилил с настройкой Active Serial x1 - не запускается.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.