Добрый день.
В проекте присутствует ядро 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 и нормально работает.

посмотрел у себя в коде, все аналогично. возникли вопросы: 1) почему в factory не рассматривается как источник сброса wdt, 2) почему wdt отключен в функции реконфигурации?

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


Это он отключён во втором варианте работы, где перезагрузка должна произойти с адресов factory. Изначально было так:

Но оба варианта не работают.

но если app-прошивка сбойная, то wdt вернет к factory. если же вы не включите wdt, то после перехода в application со сбойной прошивкой, ПЛИС повиснет. вот мне и непоятно - откуда 2 варианта функции реконфигурации для factory?

С Ваших слов возникло предположение по поводу необходимости сброса wdt для factory. Счас буду пробовать.

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

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

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

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


Функция реконфигурации:

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

Ещё накопал вот это, но не могу понять относится оно или нет к моему случаю.

если это оно, должна дергаться нога nSTATUS

Для обоих ситуаций

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

UPP: из их доки понял, что без pof checking вообще ничего работать не должно?!

хз, но проверить стоит

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

а сигналы с/на флешку идут, когда nSTATUS дергается?

Да идут.

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

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