Делаю свой загрузчик, который будет располагаться в первых 16-32к flash
Хочу оставить возможность юзерам грузить свой hex в область выше 32к, но лишить бы их возможности в этом случае прочитать мой бутлодер. В АВР есть защита от чтения бутлодера из зоны приложения, а тут вроде нет или я не прав? и как быть если нет?

А где юзер будет брать НЕХ ? Сам компилировать, или Вы ему передавать планируете? Если первое - то это уже не совсем юзер, и непонятно зачем тогда ему Ваш бутлоадер. Если второе - то это делается несколько иначе

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

А программа-прошивальщик будет уметь либо мой шифрованный прошивать, либо любой hex.

Думаю, тут должна быть однозначность - лучше только шифрованные ваши прошивки.

Может лучше в проект какой-нибудь интерпретатор forth/java/phyton добавить?

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

на AVR такие фокусы неоднократно проходили на ура, никто ничего не царапал))). Жаль что в чем то старинная атмега может быть принципиально лучше модного stm32.
Спасибо всем

Если изучить PM0042 ”STM32F10xxx Flash programming”, то можно сделать следующие выводы.

1. В STM32 память организована страницами
31 страница 1 Кб для for low-density devices
128 страниц 1 Кб для for medium -density devices
128 страниц 2 Кб для for connectivity -density devices
256 страниц 2 Кб для for high -density devices

2 Стереть можно только страницу целиком (операции перезаписи отдельных байтов не катят)

3 Писать в флеш за раз можно только 2 байта

4 Предусмотрено 2 вида защиты памяти (чтения, записи)
Защита от чтения устанавливается полностью на всю флеш память, при этом автоматически устанавливается защита записи памяти для
0-3 первых страниц для low- and medium-density devices
0-1 первых страниц для high-density and connectivity line devices
При снятии защиты чтения производится полное стирание памяти

Защита записи может устанавливаться на отдельные страницы.
Ее можно устанавливать и снимать в процессе исполнения пользовательского кода

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

Мне нужен был шифрованный загрузчик, все чудесным образом и получилось.

так в stm32 прошит встроенный загрузчик, и получается что можно с его помощью в основную flash прошить маленький кусочек кода который и прочитает всю остальную flash. Я не прав ?

Тем не менее это именно так и есть. Не удалось найти ни одного другого процика с такой функцией.
Сталкивались с подобной проблемой. У нас тоже на меге в области загрузчика кроме собственно загрузчика располагался еще и наш закрытый код управления железом. Собственно он является "изюминкой" устройства, позволяющей устройству делать то, чего не делают конкуренты. И да, покупателям была дана возможность в случае необходимости самим написать основное приложение, вызывающее функции этого закрытого кода. За восемь лет выпуска устройства (порядка 30000 штук) из примерно 20 покупателей двое запросили документацию на API нашего кода и ни один из покупателей так и не написал своего приложения. Все они в конце концов обращались к нам с просьбой доработать наше приложение под их запросы. Поэтому в новой модификации устройства на STM32 решено полностью отказаться от открытого API и предоставления пользователям возможности писать приложение, оставив лишь загрузчик с шифрованием.


Если стоит защита от чтения, то дописать что-либо вы сможете лишь стерев всю флеш.

тоже хочу переползти с атмеги на стм32. и буду делать загрузчик с шифрованием под stm32.

получается что для защиты прошивки от чтения и возможности в девайсе шифрованного обновления прошивки будет достаточно только установить флаг защиты от чтения ?
и при этом будет невозможна частичная перезапись флеша, или запись в RAM и запуск этого кода через встроенный загрузчик или с помощью отладки через JTAG ?

кстати хотел сначала сделать через USB как Mass Storage device. Потом пришел к выводу что при этом не гарантируется порядок следования данных поскольку винда будет сама определять в каком порядке писать сектора на устройстве и заполнять FAT таблицу. Что думаете об этом ?

Сейчас смотрю в сторону WinUSB. он вроде напрямую позволяет обмениваться данными с девайсом.
но тогда придется опять писать свою программу для обновления прошивки.

А почему бы не пользовать стмовский DFU? сам пользуюсь, вклеил шифрование и все довольны

удобство и простота обновления для неподготовленного пользователя.

Очень удобно и просто. Мы написали свою программу, при инсталяции она ставит DFU драйверы и регистрирует под себя *.DFU файлы. Отправляешь клиенту "Firmware v.xx.x.dfu", он вводит девайс в режим апдейт, подключает ЮСБ, двойным щелчком открывает файл и жмёт кнопку апдейт. Всё.
По поводу защиты бутлоадера, то есть такая Write protect. Кстати, была потребность исправить бутлоадер у клиента, ничего не получилось. пришлось исправленный бутлоадер писать на место основной программы, а затем при помощи него загружать основную программу (особый случай, единичный эгземпляр, срочное и не дорогое решение, прошу сильно не критиковать)