Добрый день.
В проекте присутствует ядро Remote update, всё управление происходит с помощью Nios II. Есть две конфигурации: factory и application.
Factory заливается по адресам 0x0, application - 0xd00000. Включается питание запускается factory конфигурация, которая через Remote Update загружает конфигурацию application.
Алгоритм работы для factory следующий:


Алгоритм работы для application:


Для удобства перепрошивки довавлена функция реконфигурации, алгоритм которой:


Вопросы в следующем:
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 и нормально работает.

просто можно грузиться всегда через фактори и она принимает решения грузить апликайшен или нет (целостность, кнопка, специальный флаг, коды защиты)
фактори сделать не убиваемой и не стираемой

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

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

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

а вочьдогом перегрузить?

Думаю, результат будет тот же, т.к. меняем только источник реконфигурации: была ножка ядра reconfig, а предлагаете wdt. Да и это попытка обойти то, что не работает, а не устранение самой причины проблемной ситуации. Reconfig прекрасно работает и для factory и для application, если флэшку не трогали. Вот в этом и хочу разобраться, каким образом работа EPCS/EPCQx1 Controller-a влияен на модуль Remote Update.

Почитал ещё параметры для 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?

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

???

а какая версия квартуса? вроде в 13 или 13.1 был баг то ли программера, то ли бутлодера

Версия Q14.0 и девайс 5cefa9. Там баг с Nios II Flash Programmer, он и в этой версии не работает, но какое он к данной проблеме может иметь отношение, я-то не им прошивку обновляю?

может баг не в нем (или не только в нем). ASMI от EPCQ только количеством проводов данных отличается?

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

Посмотрел на драйвера для EPCS/EPCQx1 Flash Controller, запись там по 8 бит реализована (обычный spi).

контроллер 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)).

а в момент, когда начинает reconfig глючить (когда nSTATUS дергается) какие/сколько линии данных(DQ) активны?

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

а флешка не переконфигурируется на чтение по 1 или 4 линиям? может в каком-то режиме она всегда читается по одному, без переконфигурации?