реклама на сайте
подробности

 
 
2 страниц V  < 1 2  
Reply to this topicStart new topic
> STM32F407 OPTCR, Убивается МК
Сергей Борщ
сообщение Jul 4 2014, 18:40
Сообщение #16


Гуру
******

Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095



Цитата(Golikov A. @ Jul 4 2014, 21:24) *
Понятно что рукописный бутлоадер решает проблемы, но если хотим защитить и его и иметь возможность обновлять и его, то вот...
Так если стерли - то все равно внешнюю ногу BOOT надо притягивать. А если ее притягивать, то можно уже и питание передернуть и таким образом попасть в загрузчик, а уже из него снять недоснятую защиту.


--------------------
На любой вопрос даю любой ответ
"Write code that is guaranteed to work, not code that doesn’t seem to break" (C++ FAQ)
Go to the top of the page
 
+Quote Post
Golikov A.
сообщение Jul 5 2014, 06:31
Сообщение #17


Гуру
******

Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454



тогда у меня нет вариантов... Может только как самоуничтожение?
Go to the top of the page
 
+Quote Post
alevnew
сообщение Jul 5 2014, 07:43
Сообщение #18


Частый гость
**

Группа: Участник
Сообщений: 90
Регистрация: 17-05-07
Пользователь №: 27 775



Цитата(Golikov A. @ Jul 4 2014, 22:49) *
Но в целом получив ответ его легко объяснить. Ведь действительно флэш стирается и следовательно код который должен снять лок тожеsm.gif...

Но с другой стороны, весь код который стирает флэш и лок - это установки бита "старт" в регистре, и этот код уже считан из флэша и выполнен.
Начинается процесс, который уже от софта никак не зависит (на первый взгляд). Но почему то в 4 случаях из 5 этот процесс прерывался на этапе стирания.
Go to the top of the page
 
+Quote Post
adnega
сообщение Jul 5 2014, 08:29
Сообщение #19


Гуру
******

Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702



Цитата(alevnew @ Jul 5 2014, 11:43) *
Но с другой стороны, весь код который стирает флэш и лок - это установки бита "старт" в регистре, и этот код уже считан из флэша и выполнен.
Начинается процесс, который уже от софта никак не зависит (на первый взгляд). Но почему то в 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. Забыл сказать, что прошивка после такого неудачного стирания полностью рабочая - ничего не стерлось.
Go to the top of the page
 
+Quote Post
Golikov A.
сообщение Jul 5 2014, 09:48
Сообщение #20


Гуру
******

Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454



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


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

Но думаю общее резюме что не надо работать и менять одновременно одну и туже область флэш. Наверняка если при помощи IAP попытаться менять куски кода программы во флэше, тоже будут временами такие же улеты.
Go to the top of the page
 
+Quote Post
adnega
сообщение Jul 5 2014, 10:03
Сообщение #21


Гуру
******

Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702



Глобальное стирание flash длится более 5 секунд. А это гораздо больше "пары команд".
Загадка в том, что есть какой-то способ прервать глобальное стирание программно.
Если бы RDP сбрасывался в начале сброса защиты перед глобальным стиранием, то налицо дыра в защите.
Go to the top of the page
 
+Quote Post
mantech
сообщение Jul 5 2014, 14:55
Сообщение #22


Гуру
******

Группа: Участник
Сообщений: 2 219
Регистрация: 16-08-12
Из: Киров
Пользователь №: 73 143



Цитата(Golikov A. @ Jul 4 2014, 21:24) *
Ну чисто теоретически:
Понятно что рукописный бутлоадер решает проблемы, но если хотим защитить и его и иметь возможность обновлять и его, то вот...


Все-таки так и не понял, зачем менять бут в девайсе? Как правило, это довольно простая прога, причем "вылизать" ее до блеска нет никаких сложностей, ну разве, что чисто теоретически biggrin.gif
Go to the top of the page
 
+Quote Post
Сергей Борщ
сообщение Jul 7 2014, 07:51
Сообщение #23


Гуру
******

Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095



Цитата(mantech @ Jul 5 2014, 17:55) *
причем "вылизать" ее до блеска нет никаких сложностей
То есть недостаточно тестировать? "Любая программа содержит минимум одну ошибку". Причем ошибка эта может быть чисто логической. То есть программа делает именно то, что хотел программист. Просто он не предусмотрел, что программу можно загнать в какое-то состояние вполне легальными действиями.


--------------------
На любой вопрос даю любой ответ
"Write code that is guaranteed to work, not code that doesn’t seem to break" (C++ FAQ)
Go to the top of the page
 
+Quote Post

2 страниц V  < 1 2
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 20th July 2025 - 08:15
Рейтинг@Mail.ru


Страница сгенерированна за 0.01495 секунд с 7
ELECTRONIX ©2004-2016