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

А вот тут вдруг у меня возникло такое подозрение...

Может человек говорит про микробут или что-то типа.
То есть загрузчик который берет прошивку рабочую с СД карты или что-то типа того? То есть у него нет жестко прописываемой основной программы...

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

Ну понятно, что кнопка есть, если она нажата, мы в бутлодыре, если нет то улетаем на программу.
Смысла в проверке контрольной суммы по прежнему нет.
Всегда по ресету с кнопкой попадем в бутлодырь и будем сидеть до новой прошивки.
Никаких кирпичей..

Я проверяю только примитив - если в начале лежит стекпойнтер 0x2000XXX.

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

Особого смысла в этом нет, это больше для "технически одаренных" пользователей.
Так легче объяснить, что "не играет", значит неправильную программу залил.

Извращенная логика%...

Забавно что вы не проверяете целостность прошивки. А если залилось что-то не так? А если флэш поврежден?
Счастливые люди приборы которых не могут ничего испортить))...

Бутлоадер может выдать контрольную сумму для диапазона аддрессов.
Если флэш поврежден, то ничего не поможет.
Контрольная сумма не спасает от повреждения.
Там на 99.9% повреждения будут от неправильно написаной программы, чем по другим причинам.

Но в принципе пойнт понятен. Спасибо

Смотря повреждения чего..
У меня одно устройство могло поднять тревогу и вызвать бригаду со стоимостью выезда 10-20 тысяч баксов. Если это бы произошло из-за того что прошивка неправильно записана во флэш мне бы сделали повреждение головы.
Другое устройство могло запустить систему пожаротушения основанную на шашках которые абсорбируют кислород, если бы оно это сделало в помещении с людьми оно бы их задушило
Третье устройство могло поехать и ударить в дорогущий микроскоп дорогущим объектом.

Во всех случаях я предпочту чтобы устройство не запустилось, чем сделало это...

Я в своём софте тоже проверяю только, что сектор не пустой перед прыжком, однако подход Golikov A. очень даже разумен для критических применений железа. На самом деле, повреждённый байт может привести к катастрофическим последствиям.

Ну что ж, идем на очередной круг. Не всегда есть возможность подойти и передернуть питание. Бывает, что обновление хочется сделать удаленно. И если во время такого обновления происходит сбой (связи), то с вашей проверкой на непустой сектор вы запустите нерабочее приложение и придется таки посылать человека жать на кнопку и передергивать питание. В моей и в Golikov A. реализации загрузчик обнаружит испорченное приложение и останется в режиме ожидания загрузки, давая возможность повторить загрузку. И ради чего ваши жертвы? Ради экономии 20 байт и 10 мс на проверку CRC приложения?

Я в "крупных" МК использую две области: application и image.
Когда необходимо обновить прошивку, код, работающий в application (по сути сама программа) стирает image, получает и записывает image, проверяет CRC, версию железа и версию прошивки и после этого передает управление загрузчику (через SoftReset). До тех пор, или в случае некорректного/старого image программа работает и практически не чувствует, что идет какое-то обновление.
Загрузчик проверяет корректность и версию как application, так и image. Если все CRC корректны и версия application >= версии image, то управление передается application. Если CRC у application не корректна, а у image корректна, то image расшифровывается и переписывается в application, как и в том случе, если версия image новее, затем перезагрузка. Если все CRC не корректны, то остаемся в загрузчике и мигаем светодиодом "SOS". Некоторые функции как подсчет CRC (в том числе на лету, по ходу выполнения программы), расшифровка и т.п. вынесены в область загрузчика и application их экспортирует по фиксированным адресам из таблицы экспорта (последние 240 байт загрузчика).
Из бонусов image шифрованный, сложно получить кирпич, обновление мгновенное (минимально возможное время, т.к. основная часть тратится на передачу image по GPRS|SD-карты|RS485 и т.п., а application при этом работает). Из минусов: расход памяти практически удвоенный (но image можно держать во внешней медленной/последовательной памяти, т.к. он шифрован и не отличается от того, что передается Заказчику свободно в качестве обновления), загрузчик поддерживает лишь базовые варианты управления без возможности модернизации.

У меня обновление на лету. Тоже шифрование. Нет необходимости в дополнительной памяти. В случае сбоя обновления меня не напрягает повторить. Обновление через UART. Будет GPRS - буду думать.

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

Тем не менее: "придется таки посылать человека жать на кнопку" и "получаем кирпич" немного разные вещи

Ага%) Есть и на этот случай история у меня из раздела гусарских баллад. Был на фирме программист любил сделать код и не изнурял себя защитами. В случае не запуска на объекте он всегда был готово на обновления и не видел почему те кто на объекте так ругаются.

Вот в итоге люди на объекте устали и вызывали его на обновление в командировку. Он приехал с ноутбуком, программатором и говорит, ну где прибор, ща все исправим. Ему дали лопату, указали место и сказали: прибор на глубине 4 метров мерзлой глины под землей, выкопай его, достань и обнови, а потом там в яме его подключи так как туда выведена вся подводка и гермокапсула рабочая.

Уволился он....

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

Так что кнопка нужна, но на крайний случай...

Что-то пример от ST мня загоняет в ступор

это процедура стирания флеша из исходника к AN3374
STM32F2xx in-application programming using the USART




Зачем там i+=8 ? Ну i+=4 я бы еще как то понял, т.к. запись далее идет по 32 бита.
Но сектор же стирается целиком ? Зачем вызывать процедуру стирания sectorlen/8 раз ?