В документации написано что шина данных FLASH памяти у STM32 128-ми битная.
Но при этом в коде startup, где идет инициализация переменных в ОЗУ, копирование идет по 4 байта (32 бита) инструкции


У ST есть AppNote EEPROM emulation in STM32F10x microcontrollers, где при чтении из FLASH (виртуальной EEPROM) копируются 16-ти битные данные


Как же все-таки читается FLASH?
А если мне надо только один байт прочитать из FLASH ?

Я поспешил со своим ответом. У них так и написано:

Возможно хочется обновляться штатным, но по возможности не добираясь до ноги BOOT, по команде приложению?

Только не приложению, а бутлоадеру.
Приложение может работать, а может не работать.
А свой бутлоадер может запускатся не от кнопки, или от кнопки, но от другой.
Но пользовать стандартный механизм загрузки..

Ну то есть у нас штатный запуск проца на прошивку пользователя. Которая в самом начале имеет ветвления
свой бут
стандартный бут
рабочая прошивка

и мы не трогая ножку бут имеем возможность обновить прошивку через UART?

Ну да, наверное это интересная мысль. Главное не затереть начальный разветвитель, а то придем к кирпичу

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

ну как можно потерять самопальный загрузчик? Если загрузка идет только через него, он просто следит чтобы никто не лез в область где он лежит и все. Его невозможно убить.
А вот если в ходе ветвления можно войти и в штатный процовый, то тогда он потенциально под угрозой.

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

Встроенный загрузчик тоже может глючить. Изза электромагнитного импульса, например.
Предлагаю делать резервирование - как для космоса делали: 3 одинаковых канала,
решение принимается голосованием, если 2 сказали 1, значит 1.
Так меньше вероятность глюков.
3 одинаковых СТМ, на всякий случай - а вдруг заглючит?

И 3 ФигЛи, несомненно, лучше одного. Не зря соображают на троих.

Вижу о космосе вы знаете по наслышке
2 из 3 - это для ближнего космоса, до луны край! Нормальный режим 3 из 5!

Глюк нормальной программы я больше отношу к пользователю. Найдет какую-то фигню, от другого продукта, и зальет как обновление. И здрасьте вам Кирпичь Иваныч! На эти случаи всегда даю пользователю еще попытку

Дык для этого нужно купюроприёмник добавлять. Одна надежда на Национальную Платёжную Систему: должно попроще стать. Хотя, зная наших чиновников, не очень надеюсь :-)

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

А я для каждого изделия использую уникальные ключи шифрования. Загрузчик зальет в изделие только его родную прошивку. Но все равно остается шанс, что родная прошивка сделает из изделия кирпич из-за того, что я не предусмотрел какой-то нюанс.

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

Для этого нужно оставить механизм старта бута. Если прошили хрень с правильными кодами, которая запускается и виснит. А кнопочки перейти в бут нету, вот вам и кирпич...