STM32F407 OPTCR, Убивается МК Опции

[alevnew]

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

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

Код

void UpdateOPTCR(dword v){
    v &=0xFFFFFEC;
    while (FLASH->SR & FLASH_SR_BSY){};
    FLASH->OPTKEYR = 0x08192A3B;
    FLASH->OPTKEYR = 0x4C5D6E7F;
    while (FLASH->SR & FLASH_SR_BSY){};

        FLASH->OPTCR=v;
    FLASH->OPTCR =v | FLASH_OPTCR_OPTSTRT;
    while (FLASH->OPTCR & FLASH_OPTCR_OPTSTRT){}; //?????
    while (FLASH->SR & FLASH_SR_BSY){};
    FLASH->OPTCR |= FLASH_OPTCR_OPTLOCK;
}

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

[mantech]

Сделал свой бутлоадер, вроде работает все.
Начал экспериментировать с залочкой прошивки, регистр FLASH->OPTCR.
Сделал отдельную команду для установки этого регистра, чтобы было более наглядно.

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

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

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

[alevnew]

Если не секрет, зачем это все?
....
И вообще, зачем менять залочку в своей проге?

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

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

[adnega]

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

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

В документации написано, что с Level1 должно меняться на Level0.

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

[alevnew]

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

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

[adnega]

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

[alevnew]

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

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

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

[adnega]

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

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

[alevnew]

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

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

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



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

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

[alevnew]

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

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

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

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

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

[Golikov A.]

Момент действительно неочевидный и в документации не упомянут

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

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

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

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

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

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

[Golikov A.]

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

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

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

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

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

[Golikov A.]

тогда у меня нет вариантов... Может только как самоуничтожение?

[alevnew]

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

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

[adnega]

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

Вот это загадка...
По всей видимости возникало какое-то прерывание -> ядро улетало в HardFault -> затем в блокировку.
Но как это сказывается на автомате очистки флеши и сброса RDP? Не ясно.
Почему сброс защиты подпрограммой из RAM не вызывает проблем? Не ясно.

UPDATE.
Не знаю имеет следующее отношение к теме или нет, но.
Использую versaloon для прошивки контроллеров на стадии разработки. Иногда не может стереть флеш и вылетает с ошибкой.

CODE

Info: Versaloon(0x40)by Simon(compiled on Apr 23 2014)
Info: USB_TO_XXX abilities: 0x0000176E:0x010001EF:0xC0000007
Info: Target runs at 3.288V
Info: SWDID = 0x2BA01477
Info: AHB-AP_ID = 0x24770011
Info: ROM_ADDRESS = 0xE00FF003
Info: CFG = 0x00000000, Little-endian
Info: CORTEX-M4 r0p1 processor detected
Info: CPUID = 0x410FC241
Info: STM32F2 type: XL device
Info: Chip-id read is 0x413.
Warning:Chip-id unmatch, read=0x413, want=0x411
Info: erasing flash
erasing flash |%00Info: report to author on this message.
Info: r0: 2000185C
Info: r1: 0802F8B4
Info: r2: 0000011F
Info: r3: 0000000A
Info: r4: 2000185C
Info: r5: 2001FF30
Info: r6: 0802F5FC
Info: r7: 0802F8B4
Info: r8: 00000000
Info: r9: 00000000
Info: r10: 00000000
Info: r11: 00000000
Info: r12: 02000A9B
Info: sp = 0x2001FF10
Info: lr = 0x0802120B
Info: pc = 0x08023306
Info: xpsr = 0x21000003
Info: msp = 0x2001FF10
Info: psp = 0x00000000
Info: primask = 0x01
Info: basepri = 0x00
Info: faultmask = 0x00
Info: control = 0x00
Info: SRAM dump at 0x20000000:
Info: 0000 28 48 00 28 FC D0 1E 48 1E 49 1F 4A 01 60 12 42
Info: 0010 00 D0 02 60 1D 48 1E 49 1E 4A 1F 4B 1F 4C 20 4D
Info: 0020 00 26 20 A7 3E 60 A9 46 26 1C FF 27 3E 40 B0 46
Info: 0030 24 0C 24 42 18 D0 4D 46 C7 44 1F 78 17 70 01 32
Info: 0040 01 33 0F E0 1F 88 17 80 02 32 02 33 0A E0 1F 68
Info: 0050 17 60 04 32 04 33 05 E0 1F 68 17 60 5F 68 57 60
Info: 0060 08 32 08 33 6D 1E E7 D1 07 68 0F 40 FC D1 64 1E
Error: timeout to wait for flashloader ready
Error: Fail to run flashloader command.
Info: 0070 E1 D1 0D A1 08 68 40 1C 08 60 C1 E7 FE E7 00 00
Error: Fail to erase flash.
Error: Fail to operate stm32f4.
Info: 0080 10 3C 02 40 04 00 00 00 04 00 01 00 0C 3C 02 40
Error: Fail to run command: operate.
Error: Fail to run command: program.
Info: 0090 00 00 01 00 00 00 00 3D 3C DA 28 00 28 00 01 00
Info: 00A0 01 00 00 00 01 00 00 00 00 00 00 00
| 20.04s used

Насколько я понял ошибка связана с таймаутом, отводимым на стирание.
Самое главное, что проблема иногда возникает при незначительной модификации проекта и полностью воспроизводится на разных экземплярах МК, т.е. дело в софте, а не в железе. ST-Link ничего не замечает: стирает, пишет без спотыканий. Вероятно, в данном случае возникает что-то, что мешает стереть флеш полностью, а в Вашем случае еще и защиту после этого сбросить. Буду копать...

UPDATE2. Забыл сказать, что прошивка после такого неудачного стирания полностью рабочая - ничего не стерлось.

[Golikov A.]

Вот это загадка...

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

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

[adnega]

Глобальное стирание flash длится более 5 секунд. А это гораздо больше "пары команд".
Загадка в том, что есть какой-то способ прервать глобальное стирание программно.
Если бы RDP сбрасывался в начале сброса защиты перед глобальным стиранием, то налицо дыра в защите.

[mantech]

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

Все-таки так и не понял, зачем менять бут в девайсе? Как правило, это довольно простая прога, причем "вылизать" ее до блеска нет никаких сложностей, ну разве, что чисто теоретически

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

причем "вылизать" ее до блеска нет никаких сложностей

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