Atridies 0 18 декабря, 2013 Опубликовано 18 декабря, 2013 · Жалоба Доброго времени суток, армоводы! Есть железка на Cortex-M0, в которой хотелось бы иметь возможность обновления ПО с фирменного FTP-сервера. Все части загрузчика: скачивание файла в SPI Flash, собственно запись в MCU Flash - готово. Но пока не могу всё это взаимоувязать, чтобы получился надежный загрузчик (чтобы из-за провалов питания и кривых рук персонала - не умирал насовсем). На msp430 делал следующим образом (обновление по rs485): все обработчики прерывания - были расположены по жестким адресам и обслуживали основное ПО. Сам загрузчик не использовал вообще прерывания - вся обработка была через контроль соответствующих флагов (кроме reset-а). Соответственно как бы чего не происходило - всегда после перевключения стартовал загрузчик и в этот момент его можно было перехватить (нужным пакетом на rs485) и обновить ПО. Если перехвата нет - уходим в основное ПО. Ровно сделать также на кортексе - не получается: почему-то uart-ы периодически подвисают. Вообще мне видится несколько решений задачи загрузчика: 1. Сделать работу загрузчика чисто по флагам и оставить прерывания для основного ПО. Хорошо, но пока - не получается. 2. Сделать загрузчик как часть основной программы, но тогда - все вызовы между ними надо будет делать по жестким адресам. Муторно писАть и отлаживать. 3. Сделать работу загрузчика по прерываниям, но внутри сделать ветвление: в функцию загрузчика или в функцию основного ПО. Убиваем скорость реакции. Не айс. Вопросы, которые хотелось бы прояснить для себя: 1. Какой вариант загрузчика все-таки лучше ? 2. Нет ли каких-то подводных камней при работе с флагами прерывания, но без самих прерываний ? Возможно ли это в принципе на кортексе ? Заранее спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
A. Fig Lee 0 18 декабря, 2013 Опубликовано 18 декабря, 2013 · Жалоба А там что, NVIC_SetVectorTable() не присутствует? Можно и с векторами. У нас на Кортексе М3 и сам бутлоадер можно апдейтить. Состоит из 2х независимых программ, бутлоадер стартует с ресета, дальше по условию или комманде может перейти в главную программу. Было несколько граблей, но решаемо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KRS 1 18 декабря, 2013 Опубликовано 18 декабря, 2013 · Жалоба А там что, NVIC_SetVectorTable() не присутствует? Нет, у M0 VTOR нету! Но легко эмулируется! Так что с прерываниями проблем нет! Я эмулировал - так http://electronix.ru/forum/index.php?s=&am...t&p=1095595 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 18 декабря, 2013 Опубликовано 18 декабря, 2013 (изменено) · Жалоба ..хотелось бы ..обновления ПО..чтобы получился надежный загрузчик.. 1. Какой вариант загрузчика все-таки лучше ?.. сейчас для себя решил следующее: 1) заливка принимаеся и сохраняется в штатном режиме работы, как данные. заливку пишем во флэш как новую, следующую версию. сама версия модульная. между модулями позднее связывание (на старте камня). ссылки могут быть обязательными или не обязательными, с указанием минимальной требуемой версии модуля на который ссылается. 2) после апдэйта уходим на ресет. после ресета и проверки работоспособности ядра, происходит поиск свежей комбинации софта: фулл + дифференциальные + инкрементальные версии модулей. 3) при записи во флэш определённого обёма версий - мы можем смело прореживать версии (инкрементальные между дифами), и удалять старые не используемые версии. что получается. при старте ищем свежую версию (фулл+диф+инкр), проверяем ссылки, связываем ссылки, производим запуск. если что то не так - имеем всегда одну или более предыдущих версий, на которую можем смело откатиться (инфа об успешном запуске сохраняется). плюсы а) каналы заливки - только от вашей фантазии и возможности железа-софта(работает весь ранее поставленный софт) б) нет необходимости перезаливки всегда всего камня. скорость заливки максимально быстро получается. в) в случае сбоя - всегда есть рабочая версия в памяти минусы а) отладка релизной версии модулей(не ядра) - на уровне азма(боевой вариант). дебажный так-же существует, (отдельно только данный модуль с эмуляцией окружения) - и в таком варианте уже полная поддержка студией дебаг фич. б) для модулей нельзя использовать статик адреса на память (хотя тут можно и зарезервировать бла-бла-бла, но сделал универсально). в) при некоторых операциях взятия адреса в релиз версии, требуется привести адрес к базовому адресу загруженного модуля(флэша), а не адреса компиляции. Изменено 18 декабря, 2013 пользователем kolobok0 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 19 декабря, 2013 Опубликовано 19 декабря, 2013 · Жалоба У нас на Кортексе М3 и сам бутлоадер можно апдейтить. При провале питания, во время такого обновления, потеряете своё устройство. сейчас для себя решил следующее: ... Во всех наших устройствах на М3 мы давно так и делаем: 1. ПО разделено на 2 независимых: бутлоадер и рабочее. Обновляется только рабочее. 2. Загрузка нового ПО во флешь (внутреннюю флешь программ в нерабочую область или в SPI флешь) в рабочем ПО по рабочему протоколу. 3. По завершении загрузки - выставление флага и ресет. 4. В бутлоадере: проверка наличия флага, проверка валидности ПО во флешь. Если валидно - обновление ПО и снятие флага после. 5. Переход на рабочее ПО из бутлоадера. Бутлоадер и рабочее ПО никак не связаны - при переходе на рабочее ПО, бутлоадер переходит на начальный (стартовый) адрес. Проблем с прерываниями в бутлоадере нет если правильно управлять таблицей прерывания и NVIC и инитить всю периферию с нуля. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
A. Fig Lee 0 19 декабря, 2013 Опубликовано 19 декабря, 2013 · Жалоба При провале питания, во время такого обновления, потеряете своё устройство. Мы минимизировали такую вероятность. Первый шаг при замене бутлоадера - перезапись вектор тейбл на апгрейдер, если че случится после этого, рестарт вылетит в ботлоадер апгрейдер. Потом перепрошивается весь бутлоадер и последняя стадия - запись реального вектор тейбл бутлоадера. Вероятность краша есть, но заказчик предупрежден и согласился Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 19 декабря, 2013 Опубликовано 19 декабря, 2013 · Жалоба При провале питания, во время такого обновления, потеряете своё устройство. Во всех наших устройствах на М3 мы давно так и делаем: 1. ПО разделено на 2 независимых: бутлоадер и рабочее. Обновляется только рабочее. 2. Загрузка нового ПО во флешь (внутреннюю флешь программ в нерабочую область или в SPI флешь) в рабочем ПО по рабочему протоколу. 3. По завершении загрузки - выставление флага и ресет. 4. В бутлоадере: проверка наличия флага, проверка валидности ПО во флешь. Если валидно - обновление ПО и снятие флага после. 5. Переход на рабочее ПО из бутлоадера. Бутлоадер и рабочее ПО никак не связаны - при переходе на рабочее ПО, бутлоадер переходит на начальный (стартовый) адрес. Проблем с прерываниями в бутлоадере нет если правильно управлять таблицей прерывания и NVIC и инитить всю периферию с нуля. Если залили приложение с косяком в части приёма прошивки или её записи, да мало-ли ещё чего, тоже получаете КИРПИЧ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 19 декабря, 2013 Опубликовано 19 декабря, 2013 · Жалоба Если залили приложение с косяком в части приёма прошивки или её записи, да мало-ли ещё чего, тоже получаете КИРПИЧ. Для этого у меня загрузчик имеет аварийный режим: заливка через TFTP. Через этот же режим можно делать и первичную прошивку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 53 19 декабря, 2013 Опубликовано 19 декабря, 2013 · Жалоба У нас на Кортексе М3 и сам бутлоадер можно апдейтить. Можно глупый вопрос? :rolleyes: А зачем апдейтить бутлоадер вообще, создавая при этом дополнительные возможности потери прошивки? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 19 декабря, 2013 Опубликовано 19 декабря, 2013 · Жалоба Можно глупый вопрос? :rolleyes: А зачем апдейтить бутлоадер вообще, создавая при этом дополнительные возможности потери прошивки? Не всегда можно заранее предвидеть и реализовать весь функционал, который может потребоваться от загрузчика. Ну и баг может всплыть, куда ж без этого. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mempfis_ 0 19 декабря, 2013 Опубликовано 19 декабря, 2013 · Жалоба Не всегда можно заранее предвидеть и реализовать весь функционал, который может потребоваться от загрузчика. Ну и баг может всплыть, куда ж без этого. Баги конечно возможны всегда, вот поэтому я свои загрузчики стараюсь выполнять максимально простыми - чтобы впоследствии иметь минимум потенциальных багов (тьфу-тьфу, есть множество серийных проектов, работающих на автомобилях, с простыми загрузчиками - и, слава богу, пока что ни одного кирпича, и багов в загрузчике не замечено). Работа загрузчика и обновление ПО организованы приблизительно так: - загрузчик стартует, проверяет crc32 2х банков внешней загрузочной памяти и crc32 приложения. - если во внешней загрузочной памяти сбой и приложение в порядке, то запускает его. - если во внешней загрузочной памяти всё ок, а в приложении сбой, то секция приложения обновляется из того блока загрузочной памяти, прошивка в котором помечена как новая или активная или старая (в порядке убывания приоритета), или из того блока загрузочной памяти, в котором корректное crc32. После успешного обновления запускается приложение, иначе устройство уходит в глубокий сон на 10 минут. - если во внешней загрузочной памяти всё ок и в приложении всё ок, то проверяется статус загрузочной памяти - ищется в которой из них находится прошивка со статусом новая и выполняется обновление секции приложения. В случае успешного обновления статус прошивки в области загрузочной памяти меняется на активная. В другом банке загрузочной памяти статус меняется на старая, если текущий статус банка активная После успешного обновления запускается приложение, иначе устройство уходит в глубокий сон на 10 минут. - если во внешней загрузочной памяти сбой и в приложении сбой, то устройство уходит в глубокий сон на 10 минут. Обновление загрузочной памяти осуществляется только в приложении (прошивка загружается через GPRS). В процессе загрузки прошивки контролируется принадлежность прошивки данному устройству, после завершения загрузки проверяется crc32 прошивки, и если всё ок, то устанавливается статус прошивки в банке загрузочной памяти - новая. После чего устройство перезагружается. Есть устройства с одним банком загрузочной памяти. Там вместо статусов прошивка из секции приложения сравнивается с прошивкой из загрузочной памяти (естественно если все crc32 верны). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
A. Fig Lee 0 19 декабря, 2013 Опубликовано 19 декабря, 2013 · Жалоба Можно глупый вопрос? :rolleyes: А зачем апдейтить бутлоадер вообще, создавая при этом дополнительные возможности потери прошивки? В общем это было требование начальства. Они в курсе рисков. Разработка на довольно начальной стадии, поэтому бутлоадер тоже может немного менятся. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 53 19 декабря, 2013 Опубликовано 19 декабря, 2013 · Жалоба В общем это было требование начальства. Они в курсе рисков. Ооо, ну с этим конечно, не поспоришь.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 19 декабря, 2013 Опубликовано 19 декабря, 2013 · Жалоба надо 2 загрузчика делать 1. примитивный, на 1 путь загрузки данных, не убиваемый никогда и ничем, в который схема валиться во всех критических ситуациях. Вернее она начинает работу всегда с него и если все хорошо уходит дальше. 2. уже с наваротами, изменяемый, и прочее прочее... правда что-то до 2 никогда не доходил, обычно уже шла рабочая прошивка, так как канала смены от 1 базового загрузчика всегда хватало.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 53 20 декабря, 2013 Опубликовано 20 декабря, 2013 · Жалоба надо 2 загрузчика делать 1. примитивный, на 1 путь загрузки данных, не убиваемый никогда и ничем, в который схема валиться во всех критических ситуациях. Вернее она начинает работу всегда с него и если все хорошо уходит дальше. 2. уже с наваротами, изменяемый, и прочее прочее... правда что-то до 2 никогда не доходил, обычно уже шла рабочая прошивка, так как канала смены от 1 базового загрузчика всегда хватало.... В принципе так и есть. Мне тоже хватало первого, причем загрузчик - это не ахти какая сложная прога, чтоб при тестировании не выявить принципиальные баги... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
