stm32, защита чтения бутлодера Опции

[kan35]

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

[kan35]

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

[Сергей Борщ]

Жаль что в чем то старинная атмега может быть принципиально лучше модного stm32.

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

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

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

[kusav]

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

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

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

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

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

Сообщение отредактировал kusav - Nov 10 2011, 08:29

[OVladimir]

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

[kusav]

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

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

[OVladimir]

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

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

Сообщение отредактировал OVladimir - Dec 1 2011, 06:47