Сделал свой бутлоадер, вроде работает все.
Начал экспериментировать с залочкой прошивки, регистр FLASH->OPTCR.
Сделал отдельную команду для установки этого регистра, чтобы было более наглядно.
Когда меняю биты nWRP, все адекватно меняется и записывается в Option bytes.
После удачных экспериментов с nWRP начал пробовать менять биты RDP.
RDP успешно меняю с 0xAA на другое значение (кроме 0xCC, их пока не пробовал).
При этом камень обычно подвисает намертво, но после переподачи питания все работает и RDP какой надо.

Но вот обратно сменить уровень защиты с Level1 на Level0 (0xAA) получилось только один раз - камень тоже завис, но после переподачи питания стал работать, при этом вся прошивка оказалась испорченной (стертой?). При этом RDP стал снова 0xAA.
Но вот в остальных случаях камень убивался намертво. J-Link говорит что-то типа "Core CPU locked".
Потребление питания становится минимальным.
Пожертвовал на эксперименты уже 4 МК, решил пока остановиться
Вот код изменения регистра OPTCR:



Кто-то може сталкивался, знает в чем дело?
Тактирование от HSE, HSI тоже потом включил - не помогло.

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

И вообще, зачем менять залочку в своей проге? Бут, как я понимаю, прекрасно пишет в залоченный флеш, а вот "снаружи", через JTAG\SWD к камешку уже не подлезть...

Сообщение отредактировал mantech - Jul 4 2014, 05:45

Зачем - это уже совсем другой вопрос
Сейчас вопрос - ПОЧЕМУ? В документации написано, что с Level1 должно меняться на Level0.
Ну а на вопрос зачем: во первых, изделие совсем новое, мало ли чего вылезет, если что, можно будет потом образец у заказчика взять и разобраться с внезапно вылезшим глюком.
А во вторых просто интересно, почему не работает, если должно
Готов еще тройкой-пятеркой камней пожертвовать для выяснения причины

Сообщение отредактировал alevnew - Jul 4 2014, 07:17

Попробуйте ST-Link`ом по SWD с функцией Connect Under Reset.

Там же написано, что в процессе такой смены вся флеш стирается. Так что полученный вами результат "при этом вся прошивка оказалась испорченной (стертой?)" именно такой, какой и должен быть. Баловался со снятием защиты на STM32F100, там все получалось четко в соответствии с документацией.

Да, такой результат вполне устраивает, но это было 1 раз из 5. В остальных 4-х случаях - 4 трупа, которые и без прошивки стали, и как бы залоченные остались.

Попробуйте на BOOT0 подать 3.3В и сбросить CPU. Затем перешить.

"Сбросить" - это командой встроенному бутлодырю?
P.S. Вообще очень похоже, что у всех 4-х убитых МК не сбросилась защита почему то, но флэш все же стерлась.
J-Link распознает ядро, но говорит, что залочено и стереть не может.
На уровне Level2 ядро уже по JTAG не видится совсем? Значит остался прежний Level1?

Сообщение отредактировал alevnew - Jul 4 2014, 09:44

А про встроенный загрузчик читали? Сбрасывать нужно выводом RESET.
Сейчас у Вас во флеши мусор - есть такое состояние ядра Cortex-M3, как блокировка. Делается просто: выполнив левую команду, проц попадает в HardFault, которого у Вас нет, а исключений генерить нельзя, т.к. вы уже в самом жестком исключении.

Теперь я понял Вашу мысль
Про встроенный загрузчик читал конечно, я воспринял словосочетание "сбросить CPU" как подачу некоей команды сброса встроенному загрузчику
В общем помогло, спасибо!
Я подал единицу и на BOOT0 и на BOOT1 (просто так получилось).
И со второй попытки (обязательно с паузой в несколько секунд, почему-то) команда Erase Chip из кейла через J-LINK стерла таки его.
После чего проц стал прошиваться и в нормальном режиме. И так со всеми четырьмя получилось.

В общем, для себя я сделал такой вывод - не стоит понижать уровень защиты выполнением команды из Flash. Видимо, при выполнении команды из флэша, до записи Option byte дело не доходит, ограничивается только стиранием и далее не идет. Видимо, надо эту команду выполнять из RAM. Биты защиты от записи тут не помогают.



Жалко, кнопки спасибо нет. Не нашел по крайней мере.
В общем, adnega, еще раз, огромное спасибо за наводку!

Сообщение отредактировал alevnew - Jul 4 2014, 10:23

Перенес функцию в ОЗУ - больше такой проблемы не возникает, проц разлочивается.
Проблема была в этом.

Карета превращается в тыкву?

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

Но в целом получив ответ его легко объяснить. Ведь действительно флэш стирается и следовательно код который должен снять лок тоже...

Помниться вы писали как разместить функцию в РАМ, и добавляли что так ни разу и не понадобилось, вот оно зачем оказывается...

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

P.S. А вообще размещение в ОЗУ я применял при самопрограммировании флеша на AT91SAM7, там без этого никак.

Ну чисто теоретически:

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