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 тоже потом включил - не помогло.

[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. Забыл сказать, что прошивка после такого неудачного стирания полностью рабочая - ничего не стерлось.