Обновление ПО с удаленного сервера., Как правильнее разделить ПО и самописный bootloader Опции

[Atridies]

Доброго времени суток, армоводы!

Есть железка на Cortex-M0, в которой хотелось бы иметь возможность обновления ПО с фирменного FTP-сервера. Все части загрузчика: скачивание файла в SPI Flash, собственно запись в MCU Flash - готово. Но пока не могу всё это взаимоувязать, чтобы получился надежный загрузчик (чтобы из-за провалов питания и кривых рук персонала - не умирал насовсем).

На msp430 делал следующим образом (обновление по rs485): все обработчики прерывания - были расположены по жестким адресам и обслуживали основное ПО. Сам загрузчик не использовал вообще прерывания - вся обработка была через контроль соответствующих флагов (кроме reset-а). Соответственно как бы чего не происходило - всегда после перевключения стартовал загрузчик и в этот момент его можно было перехватить (нужным пакетом на rs485) и обновить ПО. Если перехвата нет - уходим в основное ПО.

Ровно сделать также на кортексе - не получается: почему-то uart-ы периодически подвисают.

Вообще мне видится несколько решений задачи загрузчика:
1. Сделать работу загрузчика чисто по флагам и оставить прерывания для основного ПО. Хорошо, но пока - не получается.
2. Сделать загрузчик как часть основной программы, но тогда - все вызовы между ними надо будет делать по жестким адресам. Муторно писАть и отлаживать.
3. Сделать работу загрузчика по прерываниям, но внутри сделать ветвление: в функцию загрузчика или в функцию основного ПО. Убиваем скорость реакции. Не айс.


Вопросы, которые хотелось бы прояснить для себя:
1. Какой вариант загрузчика все-таки лучше ?
2. Нет ли каких-то подводных камней при работе с флагами прерывания, но без самих прерываний ? Возможно ли это в принципе на кортексе ?

Заранее спасибо.

[kolobok0]

..хотелось бы ..обновления ПО..чтобы получился надежный загрузчик..
1. Какой вариант загрузчика все-таки лучше ?..

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


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

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


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

Сообщение отредактировал kolobok0 - Dec 18 2013, 21:16