Возможен ли SUBJ при включенной защите readout protection?
Написал програмку обновления бута, при выключенном readout protection работает, при включенном нет. Копание в доках показало что страницы 0-3 автоматически защищаются от записи. Т.е бут защищен. Не страшно когда у тебя 32к и выше, но вот для 16к девайсов уже жалко флеша. Специально ужался бутом в 2к, как оказалось зря.
Получается что если планируется бут, то программа должна начинаться не ниже чем с 0х08001000, а иначе ее бут переписать не сможет. Также невозможно обновить бут.

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

Блин. Вот ведь облом. Тогда в оставшиеся после оптимизации 2к обязательно что-то запихнуть. Константы хотя бы (данные для инициализируемой секции в RAM).

Лучше оставить как есть. После обновления основной программы константы могут и измениться.
Разработчикам ST надо было сделать запись в эти страницы только программатором. Тогда эта фича сразу выплывала бы.

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

Что я и говорил это не баг, это ФИЧА. Только несколько странно то что установка защиты от чтения может привести к неработоспособности программы. Надо учитывать этот момент.

Какой STM32?

Это для всей линейки STM32F10xxx. В PM0075 на странице 17 написано следующее:
"Pages 0-3 (for low- and medium-density devices), or pages 0-1 (for high-density and
connectivity line devices) are automatically write-protected. The rest of the memory can
be programmed by the code executed from the main Flash memory (for IAP, constant
storage, etc.), but it is protected against write/erase (but not against mass erase) in
debug mode or when booting from the embedded SRAM."
Сам на эти "грабли" наступил недавно. На STM32L1 код самодельного загрузчика обновляется с установленой защитой (первого уровня. Но она там тоже с "нюансами"), а на STM32F1 уже нет. FLASH-контроллер выдаёт WRPERR бит на попытку стирания этих первых страниц. А без защиты всё ок.

Такого быть не должно впринципе.

Конечно. Для чего его обновлять? Что там такого кривого можно подсунуть? Свой это БУТЛ должен быть отлажен и трудится как часики, и нечего его трогать.
А если и трогать то, полное стирание и загрузка нового с доп фичей забытой или придуманой.

Может лучше обсудить возможно это или не возможно, а не убеждать меня что это вовсе не надо. Мне хочется на 2к доступный флеш расширить. Кто знает защита от записи в этом случае битом в WRP0 устанавливается? Бут можно в конце концов обновить из ОЗУ путем снятия readout protection, при этом флеш сотрется и, после записи нового бута, можно будет защиту снова поставить. А вот снять защиту от записи не снимая readout protection было бы интересно. Будет время на эксперименты попробую.

Не взлетит. Защита от чтения сниматся в момент сброса. А после сброса и стирания флеша заставить стартануть выгруженный в ОЗУ код можно только ногами BOOTx. Кстати, это одна из версий на недавно обсуждавшийся вопрос "зачем сделан старт из ОЗУ". Но... одно неловкое движение и имеем кирпич.
Не снимается. Проверено.

Спасибо за ответ, время сэкономил.