Запись .jic файла в EPCS через программу из NIOS II., Чтобы сделать Update прошивки в EPCS в автоматическом режиме. Опции

[FLTI]

Здравствуйте!

Хотел бы сделать возможность обновлять прошивку EPCS ( что-то типа Remote Update ) таким способом.
На плате имеется Cyclone IV с кофигурационной схемой AS с возможностью загрузки .jic файла через JTAG ( SFL ).

В EPCS находится единственный .jic файл, который был загружен туда через JTAG этой схеме.
При включении питания .jic файл из EPCS конфигурирует и инициализирует Cyclone IV.
Если этот .jic файл ( находящийся внутри EPCS ) нужно обновить ( сделать что-то типа Remote Update ), то можно ли это сделать через NIOS II не вручную, а в автоматическом режиме?
Например так - новый .jic файл передаётся с обновлением ПО, становится доступным для NIOS II и NIOS II перезаписывает новый .jic файл в EPCS, затирая предыдущий.
После следующего включения-выключения питания Cyclone IV конфигурируется и инициализируется уже с нового .jic файла.

Как это сделать?
Видимо это должна быть некая программа на C для NIOS II?
Есть ли где это описано у Альтеры, есть ли пример такой программы?

[Stewart Little]

Например так - новый .jic файл передаётся с обновлением ПО, становится доступным для NIOS II и NIOS II перезаписывает новый .jic файл в EPCS, затирая предыдущий.
После следующего включения-выключения питания Cyclone IV конфигурируется и инициализируется уже с нового .jic файла.

Давайте рассмотрим ситуацию, когда у Вас в процессе перезаписи EPCS'ки происходит сбой. В этом случае для приведения оборудования в чувство потребуется рукопашное вмешательство.

Обычно делают не так. Создается две прошивки - базовая (factory) и приложение (application). И обновление приложения осуществляется из factory-прошивки.

Почитать можно вот это: http://www.altera.com/literature/ug/ug_altremote.pdf
Ну и пример какой посмотреть: http://www.alterawiki.com/wiki/EPCS_based_...pdate%20example

[FLTI]

Давайте рассмотрим ситуацию, когда у Вас в процессе перезаписи EPCS'ки происходит сбой. В этом случае для приведения оборудования в чувство потребуется рукопашное вмешательство.

Насколько высока вероятность сбоя в процессе перезаписи EPCS'ки?
Это перестраховка или реально частые сбои?

Обычно делают не так. Создается две прошивки - базовая (factory) и приложение (application). И обновление приложения осуществляется из factory-прошивки.

Вот какая у меня ситуация.
Factory прошивка, которую надо обновлять у клиента, была залита в EPCS16 в виде .jic файла. Схема конфигурации - Active Serial.

Вот как выглядит .map файл от .jic файла:
BLOCK START ADDRESS END ADDRESS
Page_0 0x00000000 0x00068E4A
- All the addresses in this file are byte addresses
Размер .jic файла примерно 420 Кбайт, т.е примерно 1/4 от размера EPCS16.

Я планировал сделать так:
1). Записать с помощью NIOS-а ( используя соответствующие команды драйвера epcs_commands.h ) начиная с адреса 0x00080000 в EPCS16 новую Application прошивку в виде нового .jic файла.
2). Задать ( пока не выяснил - где именно ), чтобы при включении питания загрузка прошивки происходила не с адреса 0x00000000 ( там находится прошивка Factory ), а с адреса 0x00080000 ( там находится прошивка Application ).

Поскольку прошивка в виде .jic файла содержит ядро PCIe, то у меня сделано так, что конфигурирование и инициализация Cyclone 4 GX выполняется за время менее 0,1 секунды ( иначе плата с ядром PCIe не будет опознана в ПК ).
Я хотел бы понять, смогу ли я использовать Remote System Update, учитывая это ограничение по времени?

Дело в том, что имеющаяся в Remote System Update проверка того, загрузилась ли нормально Application прошивка с адреса 0x00080000 или нет, и не надо ли вернуться к прошивке Factory не имеет смысла, т.к при этом время 0,1 с ( за которое должен успеть сконфигурироваться и инициализироваться Cyclone 4 GX ) будет упущено.
По этой же причине не имеет смысла вариант когда сначала грузится прошивка Factory, а затем она грузит Application прошивку.

Значит остаётся только вариант писать новую Application прошивку в виде нового .jic файла с помощью NIOS-а ( используя соответствующие команды драйвера epcs_commands.h ) начиная с адреса 0x00000000 в EPCS16., т.е затирая при этом Factory прошивку?
Какие могут быть при этом сбои?
Ведь можно после записи прошивки сделать её чтение и проверить, а если были ошибки, то перезаписать неправильные байты заново.
Остаётся только риск того, что отключится питание во время записи или что-то ещё может произойти из-за чего новая прошивкка не перезапишется на место Factory?