Перейти к содержанию
    

Gigadevice. Boot mode в Cortex®-M23

10 hours ago, Arlleex said:

В отношении надежности так себе идея. Правильнее будет, все же, обновлять весь бинарь, а при каждом запуске проверять контрольную сумму всего образа.

А почему так себе? бинарь полностью записывается в область application кроме первых 4 байт. По окончанию прошивки ПО, CRC проверяется непосредственно из флеши application, т.е. уже прошитой, кроме первых 4 байт, которые учитываются при подсчете CRC. И если все сошлось - в этот момент прошиваются оставшиеся 4 байта. 
Проблема может произойти только в этот момент, если эти 4 байта прошьются некорректно.
Всего может быть 3 исхода: слово прошилось полностью (все хорошо); слово не прошилось вообще (тогда app не запустится); и слово прошилось неполностью и со временем может деградировать (но это такой редкий случай, реже чем совпадение CRC).

8 minutes ago, tonyk_av said:

Ну так и прописал бы это явно в скрипте линковщика: создать секцию с такого-то адреса такого-то размера в такой-то области памяти.

Я с М0 не работал, поэтому и не понял смысла загадочных "+8К".

Существует бесконечное множество решений. Я использую такой метод и M0 тут ни при чем. 

bootloader и  application - это 2 абсолютно разных проекта. им по сути друг о друге и знать не нужно

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 minutes ago, Ivan. said:

И если все сошлось - в этот момент прошиваются оставшиеся 4 байта. 

Гм. Всё-таки сложная схема, и, как мне кажется, не совсем прозрачная. Если перед стартом ПО его контрольная сумма проверяется, то имеет ли смысл такая сложная схема с первыми четырьмя байтами? С равным успехом можно писать всё приложение. Всё равно оно не запустится, если КС (контрольная сумма) не сошлась. Мне, если говорить откровенно, не совсем понятен смысл манипуляции с этим первым словом 32-бита...

P.S. На форуме было рассмотрено очень много различных алгоритмов загрузчиков. Поищите по ключевым словам "бутлоадер", "загрузчик". Очень многие проблемы и подводные камни, возникающие в таких приложениях, были многократно рассмотрены. Порой эти проблемы неочевидны, поэтому есть смысл почитать про опыт коллег:blum3:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А где хранить это CRC? если ее должен проверять bootloader, то он должен знать где она храниться или сам сохранять.
Предположим, что она храниться где-то в app. Где? в начале, в конце, в середине? это должно быть как то синхронизировано.
Если CRC храниться у bootloader-а, то опять же где? в EE? в отдельной странице? CRC должна перезаписываться при каждом новом ПО, а значит должна быть выделена целая страница для возможности стирания.

CRC передается в бинарнике прошивки. проверяется 1 раз и выбрасывается. ее просто негде хранить.

22 minutes ago, haker_fox said:

P.S. На форуме было рассмотрено очень много различных алгоритмов загрузчиков. Поищите по ключевым словам "бутлоадер", "загрузчик". Очень многие проблемы и подводные камни, возникающие в таких приложениях, были многократно рассмотрены. Порой эти проблемы неочевидны, поэтому есть смысл почитать про опыт коллег

Спасибо за совет. всегда нужно учитывать опыт других людей. Но в свое время я все это читал. конечно я уже не помню что именно я читал, т.к. эту структуру я придумал еще лет 15 назад и использовал ее еще на AVR, потом перенес на STM.
Можно до бесконечности улучшать систему. но на мой взгляд она вполне надежная и крайне экономичная

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

К примеру в AVR область загрузчика находится в конце флеши или вообще в отдельном банке (как в XMega) и запуск определяется Fuse битами. По этому application может вообще ничего не знать об загрузчике. И накатив загрузчик на любой проект я наделяю его возможностью самообновления.
В STM немного сложнее. Там старт всегда выполняется с 0x08000000 адреса (кроме случаев конфигурирования boot ножек, но они не помогут). Здесь приходится смещать app на размер предполагаемого загрузчика.

В ESP разработана другая логика обновления ПО (OTA). Она размечает область памяти на 3+ части: bootloader, app1 и app2, ...
Тем самым там храниться 2 экземпляра ПО, но на мой взгляд это очень нерационально, из условных 4 МБ - 1 МБ просто бездействует.

47 minutes ago, haker_fox said:

Мне, если говорить откровенно, не совсем понятен смысл манипуляции с этим первым словом 32-бита...

Это эквивалент флага true и false. только не занимающий ни одного лишнего бита данных.

Где-то это 4 байта, в AVR - это 2 байта, в STM32F3xx (если не ошибаюсь) - это 8 байт. Главное, чтобы это был минимальный размер прожига.
В STM32L1xx, кстати, оказалось, что стертая страница имеет не FF, а 00

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

51 minutes ago, Ivan. said:

им по сути друг о друге и знать не нужно

ИМХО, как раз наоборот.  Скрипт линковщика должен быть общим, чтобы правильно разместить код и данные двух приложений в памяти одного МК, при этом проверит, чтобы не было перехлёстов там, где их быть не должно, и, наоборот, перекроет то, что можно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если говорить об STM, то в проекте application нужно просто ограничить FLASH MEMORY:
FLASH    (rx)    : ORIGIN = 0x8000000 + 8K,   LENGTH = 32K - 8K

а в bootloader:
FLASH    (rx)    : ORIGIN = 0x8000000,   LENGTH = 8K

и никакого нахлеста не может произойти

Bootloader даже не знает как размечена память. он только знает, что app должен размещаться после загрузчика, а дальше его не волнует.
В файле обновления есть только сигнатура board-а, версия прошивки, размер и КС. При последовательном получении прошивки - загрузчик стирает только те страницы, которые перекрываются новым ПО. остальные страницы не затрагиваются и app может размечать их на свое усмотрение (настройки, журналирование, файловая система и т.д.)

Кстати, помимо CRC bootloader еще должен хранить размер application. Т.е. это уже ~8 байт нерационально использованной памяти

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, Ivan. said:

это должно быть как то синхронизировано.

Естественно. Но ведь авторы загрузчика и ПО могут договориться, особенно, если это одно и то же лицо. Я, например, всегда хранил в конце памяти программ. Последние 32-бита были заняты под КС.

2 hours ago, Ivan. said:

а значит должна быть выделена целая страница для возможности стирания.

Не вижу в этом проблемы.

1 hour ago, Ivan. said:

Т.е. это уже ~8 байт нерационально использованной памяти

А какой смысл экономить единицы байт при нынешних размерах флеш-памяти? Помню, даже во времена ATmega16, когда было 16 кБ памяти, всегда оставалось несколько сотен свободных байт. Иначе, ИМХО, делать и не стоит: не остаётся запаса на будущее.

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

1 hour ago, Ivan. said:

В STM32L1xx, кстати, оказалось, что стертая страница имеет не FF, а 00

Вот-вот:blum3:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 часа назад, Ivan. сказал:

Проблема может произойти только в этот момент, если эти 4 байта прошьются некорректно.

Вот именно. А вот надежда на

Цитата

...такой редкий случай, реже чем совпадение CRC...

весьма опрометчива, т.к. даже кусок Flash, прошедший валидацию Вашим методом, при определенных обстоятельствах может быть деградирован. Например, если девайс работает при высоких температурах, или когда кусок бинаря попал на участок Flash, отведенный в предыдущей версии ПО под некий кольцевой журнал, ресурс памяти там износился и т.д. со всеми вытекающими. Т.е. однажды при включении во Flash окажется не то, что было при прошивке и подсчете CRC. Ваш метод передаст управление на это "дырявое" ПО, а при полной проверке CRC - нет. К тому же, на современных кортексах сверка CRC всех их мегабайтов Flash - дело быстрое, иногда даже быстрее, чем установится флаг готовности всяких генераторов и PLL.

Цитата

А где хранить это CRC? если ее должен проверять bootloader, то он должен знать где она храниться или сам сохранять.
Предположим, что она храниться где-то в app. Где? в начале, в конце, в середине? это должно быть как то синхронизировано.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 minutes ago, haker_fox said:

Не вижу в этом проблемы.

А зачем? когда все решается гораздо проще. У всех разное решение, я решил не тратить ни сантиметра.
А с AVR, как я уже сказал, и договариваться не нужно

 

10 minutes ago, haker_fox said:

Вот-вот:blum3:

😀 не считаю это проблемой. просто пришлось подправить проверку if (firstWord != 0x000000UL) ...

3 minutes ago, Arlleex said:

Вот именно. А вот надежда на

а при записи CRC нет такой проблемы?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 минуту назад, Ivan. сказал:

а при записи CRC нет такой проблемы?

А причем тут запись? Запись не интересна - интересна передача управления в надежно цельный кусок памяти.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 minutes ago, Ivan. said:

гораздо проще.

 

5 minutes ago, Ivan. said:

не считаю это проблемой

Дело Ваше:blum: Главное, не наступите на те грабли, про которые написано в темах о загрузчиках на этом форуме.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

  

5 minutes ago, Arlleex said:

Проблема может произойти только в этот момент, если эти 4 байта прошьются некорректно.

это может произойти только когда в момент записи сняли питание и данные не глубоко въелись. Обновление ПО выполняется человеком и если питание пропадет и человек не обратит на это внимание, а попробует запустить девайс - ну уж извините.

Ладно. Спасибо за советы, я их учту

Кстати, девайсик полностью заработал на GD вместо STM

image.thumb.png.e7bd99493cf32cfe0c7fe7066119ae95.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

51 минуту назад, Ivan. сказал:

это может произойти только когда в момент записи сняли питание и данные не глубоко въелись...

На самом деле это не совсем так... Flash вполне себе деградирует при выключенном питании.

Цитата

Обновление ПО выполняется человеком и если питание пропадет и человек не обратит на это внимание, а попробует запустить девайс - ну уж извините.

Понятно. Если юзер сам следит за обновлением, тогда, наверное, да. Я же свои девайсы вообще после продажи не сыщу:wink:

Цитата

Кстати, девайсик полностью заработал на GD вместо STM...

Что это за устройство?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 minutes ago, Ivan. said:

это простенькое устройство https://eridan.ru/ip535_07ea_rs

Учитывая специфику работы устройства, добавьте же проверку КС перед пуском программы. Это несложно. Но возможно спасёт жизни людям.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...