Бутлоадер

[vinni_puh]

Добрый день!

Завершаю свой проект, но на последнем этапе требуется помошь, господа коты, подскажите!
Коротко - делаю блок управления более-менее "умной" логикой на объекте.
К центру прицеплено по РС485 куча датчиков, от них собирается телеметрия, обрабатывается, и передается на сервер через IP-сеть. Тут долго рассказывать... тема узкоспецифическая. Кодил это последние 4 месяца, все завершено.

В центральном подуле основа - проц 18F26K22, к нему помимо всего прочего прицеплен ЕНЦ 28J60, и nor-флешка.

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


Подскажите пожалуйста, конкретными советами (ибо морально силы на исходе), требуется слепить это воедино. (т.е БУТ и основную прошивку, на 26К22). Поскольку прерывания в 26К22 расположены в начале процессорной памяти, нет никакой возможности расположить весь бут целиком в начале процессора. Логика подсказывает, что в 0-м оффсете процессора надо разместить что-то типа
asm("goto OFFSET"), и в этом оффсете расположить БУТ, с последующим возвратом в точку расположенную прямо после первой инструкции в начале процессора(ну а там БУТ будет решать, скопировать из NORa чего-то или просто вернуть управление).


В процессе написания описанного монстра нигде не применял дополнительных опций компилятора и линкера, только выставил оптимизацию в normal, ну.. где выставляется offset видел, указывать пробовал, но вопрос как их соединить все равно открыт.

Вот допустим, создаю 2-й проект-BOOT, помимо основного, в котором делаю всю логику БУТа. Как собрать их воедино? Как сделать чтобы в нулевом оффсете PICa располагалось asm(goto...)

Компилятор ХС8 1,45, МПЛАБ Х последней версии, проц повторюсь, PIC18F26K22, хотя кстати собрал этот же проект и под 27К40, там памяти в 2 раза больше, но как оказалось мне и в 26К22 все шикарно влезло, места для БУта достаточно.



И второе. Для начала, я хочу собрать единый ХЕКС для прошивки.
А как получить BIN, который буду записывать в NOR через удаленку? непосредственно пригодный для копирования в процессор?

[КРАМ]

При написании на Си, потребуется писать скрипт линкера. Мануал на линкер имеется в хелпе мплаба.
Нужно так же ознакомится с размером стираемых страниц флеша в МК и расположить бут в пределах определенного количества этих страниц так, чтобы на эти страницы не попадал остальной код. Собственно границы страниц и указываются в скрипте линкера. Располагать бут в начале нет никакой необходимости.
Некоторая проблема возникает с прерываниями. Либо Вы их в буте вообще не используете, либо отказываетесь от перепрошивки нулевой страницы флеша и оборачиваете обработчик нестираемым семафором, который переключает обработку между основным кодом и бутом. При этом возрастает латентность обработчиков прерываний. И тогда бут оказывается в начале флеша.
Получение BIN не обязательно, можно загружать и HEX, преобразуя его на лету в дамп памяти. В любом случае, этим дОлжно заниматься либо ПО в самом МК, либо внешнее ПО, осуществляющее загрузку в МК.
Если предполагается шифрование загружаемого потока, то BIN вообще не нужен, внешнее ПО преобразует HEX в любой удобный для загрузки формат и шифрует его.
А вообще, есть аппнота по буту для 18-х ПИКов, правда бут там типовой и использует для загрузки типовое ПО Микрочипа.
ЗЫ. Никаких goto не требуется. Просто нужно, чтобы main территориально относился к буту. Основной цикл будет содержать две ветки - application и bootloader
Я, например, предпочитаю применять буфер загрузки, разделяя флеш ровно пополам на собственно весь код, включая бут, и буфер загрузки. В рабочем режиме фоновым образом грузится новая прошивка, а затем подается команда на перепрошивку и устройство АВТОНОМНО и очень быстро (примерно за 2 секунды на 5000 строк кода в dsPIC33) перегоняет данные буфера в исполняемый флеш.

[-=Vovka=-]

Лично я бутлоадер всегда располагаю с 0 адреса. Естественно ставлю защиту от стирания.
У меня всегда два проекта: бутлоадер и основная программа.
В опциях линкера основной программы указываю адрес, доступный для перепрошивки и все это, если нужно объединить после компиляции "автоматом" соединяю программой PicHexEdit
В дальнейшем работаю только с основным проектом - бут уже есть.
В буте при старте МК по какому-то флагу определяю что делать: запускать основную прошивку или перепрошивать

[КРАМ]

Бутлоадеры условно можно разделить на два типа: те, которые предназначены для заливки в устройство лежащее на столе (доступное непосредственно) и те, которые работают с удаленным устройством.
И эти два вида - "две большие разницы". И по надежности и скорости канала связи и по возможности влиять на ситуацию руками (сбросить МК или нажать на некую кнопку, подключить другое ПО или задействовать другой интерфейс...).

[vinni_puh]

Спасибо, поковыряю документацию по линкеру, после чего продолжу задавать вопросы).

Мой случай - удаленка. Я могу долго и упорно отсылать пакеты во флешь, пробивая их через любой степени хреновости UDP-сеть, проверяя и перепроверяя корректность доставки, лишь бы оно вообще хоть как то работало))). Все это делается софтверно. После окончательной записи, активирую соотв. флаг в конфиге, предназначенный для скармливания БУТу, отправляю в устройство РЕСЕТ-команду, и после этого уже ни на что не могу повлиять, оно должно будет получить и записать что требуется через SPI-NOR.
Сам БУТ прерывания использовать не будет, там только SPI без прерываний.

[-=Vovka=-]

vinni_puh писал(а):

А как получить BIN, который буду записывать в NOR через удаленку? непосредственно пригодный для копирования в процессор?

Отправляете HEX - в бут сам все разруливает.

[КРАМ]

При удаленной прошивке работа с HEX увеличивает объем передаваемых данных минимум в 2,5 раза.
При этом, никак не решает вопрос с шифрованием. Если прошивку шифровать, то придется:
а) писать шифрующее ПО
б) корректировать бут из аппноты.
При этом исчезает профит от использования собственно HEX-а. Есть смысл при шифровании изменить формат на бинарный и внести изменения в бут Микрочипа и в этой части.

Добавлено after 5 minutes 20 seconds:

vinni_puh писал(а):

и после этого уже ни на что не могу повлиять, оно должно будет получить и записать что требуется через SPI-NOR.

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

[-=Vovka=-]

КРАМ писал(а):

В Вашем методе (если я его правильно понял) очень высокая вероятность получить удаленный "кирпич".

Память делится на две области: в одну из них заливается новая прошивка и где-то для нее хранится контрольная сумма. Бутлоадер при старте смотрит флаг с какой прошивкой работать. Проверяет контрольную сумму и если она не совпала переходит на работу с предыдущей версией прошивки...

[КРАМ]

А что с прерываниями делать?
Вектора одни на обе прошивки.

[-=Vovka=-]

Так прерывания все равно ж буте перенаправляются - по флагу и переходить

[КРАМ]

А ничего, что латентность у прерываний растет? Там и так достаточно семафоров из-за единых на все векторов всего двух обработчиков.
Впрочем, тут дело вкуса. Можно и не переписывать принятый код. Смысл буферизации от этого не меняется. Главное, не гнать принятые данные сразу в исполняемую часть, даже если запуск произойдет только после верификации.

[vinni_puh]

Спасибо за комментарии!

>>В этом и проблема. Все замечательно, если во время обмена и прошивки не будет потеряно питание (даже кратковременно).

Да, веселье... вообще, есть изделия работающие по такому принципу, сейчас сооружаю аналог. До сих пор пока еще "проносило",
но очевидно что однажды оно случится. Вероятность на самом деле минимальная... но может быть, поскольку изделие будет стоять к примеру в трансформаторной будке, чердаке, и.т.д.

Во время обмена - нет. Каждый фрагмент отправляется отдельно, и я могу контролировать по отдельности. Пока я удаленно не верифицирую корректную запись каждого фрагмента - я не разрешу активацию БУТа.



Отсюда родом и была мысль, в нулевое смещение писать "GOTO OFFSET BOOT", а из бута возвращать назад. Т.е, в процессе незавершенной
прошивки возможны только 2 состояния:
1. либо ВСЯ ПАМЯТЬ кроме БУТа будет стерта (FF), либо,
2. как минимум 0-я страница будет содержать содержимое, в этом случае степень незавершенности будет неважна, поскольку управление передастся на БУТ,
а он начнет процесс заново - т.е если в общем конфиге нет маркера что прошивка завершена, значит бут получив управление сотрет все что есть, кроме самого себя, не вдаваясь в детали. А внешний конфиг (всего аппарата) хранится в SPI- флеши, и не затрагивается ничем, если только специально не записать.


При этом стирать страницы не с начала к концу, а от конца к началу. Насколько я помню, вектор прерывания в 26К22 расположен на 1-й странице памяти, а размер стираемой страницы - 64 байта.
Т.е либо будет стерто абсолютно все кроме БУТа, либо сохранится 0-я страница, вместе с командой перехода.
И понятно кстати, что даже если БУТ выполнить в виде функции внутри основного проекта, все равно придется внутри описать всю инициализацию, SPI в частности, и прикладные флешь-функции.

Что скажете? только сильно не бейте)))


Сейчас пока теоретизирую "на пальцах", но и в остальной части проекта сначала долго продумывал в уме.




В процессоре 26К22, равно как и в 27К40 мало места, чтобы держать в памяти самого проца точную копию кода. Еще мыслима красивая идея держать в внешней флеши несколько версий, и активировать ту или иную по необходимости (так делается, видел), но флешь неподходящего размера все же.

По этой же причине расточительно передавать по сети HEX, да вообще, зачем заставлять аппарат что-то делать, если это можно сделать софтверно?
Только я не знаю пока, как читать ХЕКС, вот и спрашивал про программу. Кстати, спасибо!

И да, потом будет криптография. ПК-часть у меня на том же самом С что и ХС8)))), только размерность int другая, так что функции можно будет применить общие, и примерно одновременно.

[vinni_puh]

Так). То что изложил "на пальцах", на практике заработало! Базовая программа пишет во внешнюю флешь настройку активации для БУТа, который ее читает, пока что промигивает 100 раз диодом, снимает флаг активации и благополучно передает управление назад.

Слепил из 2-х отдельных проектов, покамест, хотя идея расположить БУТ внутри базового проекта нравится.


Благополучно нарвался на переполнение стека... ибо передавать управление надо не из 4-й вложенной функции.


Теперь вот что, дальше надо писать отправку бинарника во флешь. Хотя описание ХЕКСа теперь понятно), порылся и нашел программу,

hex2bin v2.5, Copyright (C) 2017 Jacques Pelletier & contributors

при рассмотрении полученного бинарника "под микроскопом" вроде бы все соответствует.
Кто-нибудь юзал? Сойдет для быстрого старта?

Вложения

Hex2bin.rar

(182.35 KiB) Скачиваний: 250

[-=Vovka=-]

У меня NOD32 ругается, что в файле вирус!

[vinni_puh]

Только сама прога.

В том архиве еще и исходники.. и другие файлы

Вложения

hex2bin.rar

(21.69 KiB) Скачиваний: 225

[-=Vovka=-]

Так же ругается на вирус!!!

[vinni_puh]

https://sourceforge.net/projects/hex2bi ... t/download
Отсюда взял.
Поверю щас CureITom. У меня NOD чет молчит на это.

[-=Vovka=-]

По ссылке в файле нет вируса! Лови живность у себя на компе...

[Мурик]

В этом архиве вирусов нет. https://www.virustotal.com/ru/file/ae5d ... 529695627/
NOD32 как и другие антивирусы ничего не нашел. Ищите проблему в вашем компе. Может у вас вирус, который заражает скачиваемые файлы.

[vinni_puh]

Да ладно, хрен с этим! (я кстати НОД обновил, и CureIT и НОД молчат, и скрытые файлы все вижу).
Кто какого мнения о проге?))