[pokk 0]

Добрый день, подскажите с  алгоритмом бутлоадера. Устройство (stm32) содержит 3 области памяти bootloader, сама прошивка(app), и блок настроек (Setting тут находиться IP адрес, mac  и тд ).

Пока рассматриваю следующий алгоритм.

1) При включении устройства сразу попадаем в загрузчик там сверяем CRC прошивки (appl), если CRC сошлась то переходим в него, если нет то остаемся в bootloader и ждем прошивку. 

2) При обновлении прошивки,  загрузчику  предается шапка app в которой содержаться ID, CRC, размер страницы, и тд..  а после сама прошивка.

это я уже частично реализовал, остались следующие вопросы:

1) Как сделать переход из appl обратно в  booloader ? При получении шапки прошивки в appl(без ответа TFTP на этот пакет) установить байт в озу на обновление , и сделать  программный  reset, и при повторном запросе(по таймауту, так как не было ответа) шапки appl принять её уже в загрузчике и начать обновление.

2) Какой IP установить загрузчику дефолтный свой ? Так как ip у приложение может смениться пользователем, и после reset загрузчик, не поймает пакет, так как будет находиться на другом IP.

Можно из bootloader считывать область настроек, и доставать от туда IP, но при первом прошитии bootloader, секции настроек нету.

Можно считывать секцию setting  и проверять её CRC и в случае отсутствия устанавливать дефолтный ip, но как потом выяснить какой же ip установился ?

3 ) В каком формата передавать прошивку hex или bin?  Пока не вижу преимущества hex формат, только больший геморрой с парсингом и со склеиванием кусков, до размера страници flash. 

 

 

 

[haker_fox 60]

Почитайте тут совсем свежая тема.

[jcxz 184]

2 часа назад, pokk сказал:

Пока рассматриваю следующий алгоритм.

Бутлоадеры тут обсасывались 100500 раз. Воспользуйтесь поиском.

Цитата

Можно считывать секцию setting  и проверять её CRC и в случае отсутствия устанавливать дефолтный ip, но как потом выяснить какой же ip установился ?

"Потом" - это когда? Выражайтесь яснее, телепатов тут нет.

Можно присвоить устройству 2 IP: 1-й конфигурируемый, 2-й - фиксированный. Когда забыли 1-й - подключаемся к устройству напрямую кабелем (без роутеров и подсетей) по 2-му IP.

Цитата

3 ) В каком формата передавать прошивку hex или bin?  Пока не вижу преимущества hex формат, только больший геморрой с парсингом и со склеиванием кусков, до размера страници flash. 

Если прошивка состоит из несмежных регионов памяти - hex имеет преимущества. Так же там могут быть секции, не отображаемые во flash.

[Михась 2]

А зачем вообще TFTP? Сделайте свой клиент-прошивальщик с блэкджеком. TFTP хорошо если надо файл залить на носитель с файловой системой.

[jcxz 184]

3 минуты назад, Михась сказал:

А зачем вообще TFTP? Сделайте свой клиент-прошивальщик с блэкджеком. TFTP хорошо если надо файл залить на носитель с файловой системой.

Автор боится "геморроя с парсингом и со склеиванием кусков, до размера страници flash", но при этом ему совсем не страшен в 100 раз больший геморрой с реализацией FTP-протокола.

Интересно только - как он внешнему FTP-клиенту объяснит, что надо делить отправляемый файл согласно границам страниц флешь?  

[Михась 2]

TFTP примитивный, даже я его быстро применил, экземплы у ST есть. Но если бинарник заливать, то он вообще не нужен. Свое консольное приложение быстрее написать.

[pokk 0]

17 hours ago, jcxz said:

Если прошивка состоит из несмежных регионов памяти - hex имеет преимущества

Можно по подробнее, это как у меня секция приложения и секция настроек ? или Когда приложение разбивается на несколько секций ? А для чего такое, используют? 

Я тут по смотрел, моя прошивка занимает где-то только  30% памяти, остальное в hex, bin забито 0xFF,  можно ли как то правильно заливать только ту часть которая содержит прошивку, без стирания всего flash? Все же приятнее, если прошивка залетает за пару секунд а не десяток.

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

 

[haker_fox 60]

2 hours ago, pokk said:

Можно по подробнее

bin не несёт информацию об адресах, а hex - содержит. Таким образом, в hex  у вас могут быть данные для нескольких адресных пространсв.

[jcxz 184]

3 часа назад, pokk сказал:

Можно по подробнее, это как у меня секция приложения и секция настроек ? или Когда приложение разбивается на несколько секций ? А для чего такое, используют?

Для размещения данных/кода в разных несмежных регионах памяти.

3 часа назад, pokk сказал:

Я тут по смотрел, моя прошивка занимает где-то только  30% памяти, остальное в hex, bin забито 0xFF,  можно ли как то правильно заливать только ту часть которая содержит прошивку, без стирания всего flash?

Открыть свойства проекта IAR: Options\Linker\Checksum, поставить галку "Fill unused code memory" и задать другие границы "Start/End address".

3 часа назад, pokk сказал:

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

А зачем вы передаёте управление в адреса за пределами прошивки??? 

[RusikOk 1]

В 01.04.2019 в 14:05, Михась сказал:

А зачем вообще TFTP?

любой самый плохой стандарт лучше его отсутствия

[Михась 2]

Ну и тогда про стандарты - TFTP в базе не умеет удалять файлы, на сколько я вспомнил. А при маленьком объеме файловой системы это уже очень важно. Можно обойти заливкой специального командного файла, который содержит имя удаляемого файла. Но это уже будет нестандартная надстройка над TFTP.

И еще надо подумать, что бутлоадер помимо стека TCP/IP потянет за собой файловую систему.

 

Изменено 16 января пользователем Михась

[RusikOk 1]

2 часа назад, Михась сказал:

TFTP в базе не умеет удалять файлы

можно перезаписать файл

 

2 часа назад, Михась сказал:

помимо стека TCP/IP

обычно он там и так и так будет. раз решились делать загрузчик по TFTP

 

2 часа назад, Михась сказал:

потянет за собой файловую систему.

не обязательно если нужно перешить только flash контроллера