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

Хотел бы сделать возможность обновлять прошивку 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?
Есть ли где это описано у Альтеры, есть ли пример такой программы?

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

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

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

Для записи EPCS/EPCQ используйте EPCS/EPCQx1 Flash Controller или ASMI Parallel. Учитесь читать/писать флэшку, далее принимаем/записываем праграмму (всё это делает функция "загрузчик"), стартуем FPGA. Когда всё заработает, смотрим - кто такой Remote Update, делаем всё, как написано выше.

Я что-то подобное и хотел сделать с использованием EPCS/EPCQx1 Flash Controller.
Как через NIOSII научиться читать/писать EPCS ( реально использую M25P16 ) ?
Это ведь проще, чем Remote Update? Хотя , конечно есть и риск из-за возможного сбоя.

Не понял Вашу фразу - Когда всё заработает, смотрим - кто такой Remote Update, делаем всё, как написано выше.
Ведь писать в EPCS через NIOSII - это и есть по сути Remote Update?



В ug_altremote.pdf по Cyclone IV информация идёт с стр.23 и упоминается файл RSU.zip , который непонятно, откуда взять.
В директории Квартуса 13.1 его нет...
Не могли бы Вы его сюда запостить.

Remote Update для "просто" перезаписать прошивку не нужен, а нужен для возможности переключения между двумя хранимыми в памяти прошивками.

Это к тому, что сначала разбираетесь, как писать/читать EPCS при помощи EPCS Controller-a, а потом разбираетесь с Remote Update (тут Remote Update - название IP-ядра, к записи прошивки отношения не имеет, только переключает прошивки, позволяет выбрать нужную при старте FPGA).

Ок, понятно, надо писать в EPCS, но в другую её область, чтобы не затереть исходную прошивку.
Где доступнее всего описано с примером ( в том числе с программой на С для NIOSа ) - как писать/читать EPCS через NIOS при помощи EPCS Controller-a ?

Можете взять в качестве примера немного подправив (используются только ф-ии alt_epcs_flash_init(), alt_epcs_flash_erase_block(), alt_epcs_flash_write_block(), ну и если читать надо, тогда - alt_epcs_flash_read_block()):


Ранее, для загрузки по CAN, использовался немного другой вариант:




Чтобы FPGA стартовала - записываете прошивку с адреса 0.

Тут ещё вот какая засада притаилась: http://www.altera.com/support/kdb/solution...182014_477.html

Установите q14.0 (на ftp есть таблетка) и всё точно будет работать.

Спасибо за пример, в Эклипсе скомпилировался без ошибок!
Я в С не силён, разбираюсь сейчас по тексту.
Нет ли у Вас этого исходника с комментариями?
Если нет, то поясните пожалуйста, что такое idx?

idx - это номер блока данных (прошивка в данном случае передаётся по TFTP, размер блока данных 512 байт, последний блок может быть меньше 512).
Вам необходимо просто при приёме прошивки правильно формировать адреса, куда будут ложиться данные. Перед записью данных необходимо стирать страницу, которая будет записана. Можно стереть сразу всю область памяти занимаемую прошивкой, но это долго, для варианта с TFTP не подходит (не дождётся ответа). Для второго варианта (загрузка по CAN, ждем ответа о выполнении стирания сколь угодно долго) использовалось полное стирание памяти перед началом записи.
Особого внимания приведённому коду уделять не стоит, просто пример функций используемых для записи EPCS/EPCQ.

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

Вот какая у меня ситуация.
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?

Это всё делается через регистры ядра RSU.


Для управления ядром RSU я делал user IP для Ниоса, всё управление RSU выполняет софт. Тут времени понадобится больше. Если сделать железный контроллер для управления RSU, думаю, в 100 мс вполне уложится (ещё, правда, от конфигурационного девайса будет зависеть и файл прошивки ужать. Можно поставить epcq-флэшку для загрузки в режиме 4х).

Железный контроллер для управления RSU придётся делать с нуля или у Альтеры есть что-то готовое?
У меня и так с учётом компрессии и прочих ухищрений ( отдельный клок 40 МГц через CLKUSR вход и ещё кое-что ) это время на пределе ( примерно 80 мс ), но всё работает устойчиво.
То есть на что-то ещё дополнительно остаётся 10 -15 мс.
В итоге получается, что остаётся только рискованный способ - без RSU напрямую писать по нулевому адресу EPCS?

Какие приёмы обычно используют, чтобы надёжно писать в EPCS?
Я буду писать со стороны ПК через промежуточную On-chip memory ( dual-clock / dual-port ) размером чуть меньше 1Кбайт ( 1Кбайт минус 16 байт ) .
С одной стороны в эту память ПК пишет данные из RPD-файла ( примерно 500Кбайт ), а с другой НИОС читает эти данные и через команду epcs_write_buffer ( из драйвера epcs_commands.h ) записывает их кусками ( 1Кбайт минус 16 байт ) в EPCS.
Поскольку память при одновременным доступе на запись и на чтение по одному и тому же адресу ( а это может произойти ) возвращает значение Don't care , то как обычно делают, чтобы избежать этой проблемы?
Если использовать биты готовности ( для handshake ) , то в отношении их тоже есть вероятность того, что произойдёт одновременный доступ по адресу, где находится этот бит готовности.
Как тут быть?
Есть ли тут какое-нибудь стандартное решение?