[makc 217]

11 минут назад, MrBearManul сказал:

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

В option byte есть бит WDG_SW, который позволяет запускать watchdog аппаратно, сразу после старта МК. Чем он Вас не устроил?

[MrBearManul 0]

6 минут назад, makc сказал:

В option byte есть бит WDG_SW

Да, в стэмках есть. Я был не объективен, и сказал об общей ситуации, т.е. о микроконтроллерах и других фирм, которые подобного бита не имеют. Также есть личное мнение, что отдельная внешняя микросхема несколько надёжнее, чем то, что находится внутри защищаемого МК.

[makc 217]

28 минут назад, MrBearManul сказал:

Да, в стэмках есть. Я был не объективен, и сказал об общей ситуации, т.е. о микроконтроллерах и других фирм, которые подобного бита не имеют.

Это другое дело, в общем случае внешний WDT никому еще не вредил.

28 минут назад, MrBearManul сказал:

Также есть личное мнение, что отдельная внешняя микросхема несколько надёжнее, чем то, что находится внутри защищаемого МК.

Согласен, минусов у внешнего WDT не так уж много: лишняя площадь на плате, деньги и пины на МК, которые придется под это задействовать. Но в данной теме речь всё же идет про STM32 и его особенности. ;-)

[Arlleex 173]

"Видишь суслика? Вот и я не вижу... А он есть!"(с)

Вообще говоря, архитектура ядра Cortex-Mx разделяет типы сбросов на сброс по питанию, системный сброс и сброс отладчика.
В новых TRM на Cortex-Mx этого не пишут, но в TRM на Cortex-M3 (r1p1) этому вопросу уделен хоть и не большой, но целый параграф.

Сброс по питанию это

Цитата

Reset at power up, full system reset. Cold reset.

Системный сброс это

Цитата

Reset of processor core and system components, excluding debug.

Сброс отладчика это

Цитата

Reset of SWJ-DP logic.

Кроме того, системный сброс - наследуемое событие от сброса по питанию


Детальное описание каждого типа сброса, при желании, найдете сами.
Главное тут то, что при системном сбросе не сбрасывается отладочная логика, в отличие от сброса по питанию.

Теперь, вкупе с теми цитатами из RM на МК, что я писал где-то в начале топика, добавлю сюда еще одну из раздела с описанием байтов опций

Цитата

The option byte can be read from the memory locations listed in Table 11 or from the Option byte register (FLASH_OBR).
Note: The new programmed option byte (user, read/write protection) are not loaded after a system reset.
To reload them, either a POR or setting to '1' the OBL_LAUNCH bit is necessary.

Чуть дальше

Цитата

On every power-on reset, the option byte loader (OBL) reads the information block and stores the data into the option byte register (FLASH_OBR) and the write protection register (FLASH_WRPR)...

Что ж, типичные проявления механизма "делают одни, документацию пишут другие"
Для индусов (или кто там им доки пишет?) что системный сброс, что сброс по питанию - одного поля ягода. Сброс же

Как мне кажется, OBL_LAUNCH внутренне является системным сбросом, но до входа на "ИЛИ" ответвляется на сброс отладочной логики


Еще, кстати, Errata подталкивает на мысль, что у них там есть какая-то логика при сбросе, которая определяет уровень доступа отладчика

Цитата

2.1.4 RDP Level 1 issue
Description
When the RDP Level 1 protection is set, there exists a logic issue that compromises protection of the Flash memory against debugger access. When the debugger is connected to the device, the first transaction with the Flash memory after a power on reset/power up is granted because of a race condition existing between this debugger access and the protection mechanism of the Flash memory. As a result, the debugger may access one data in the Flash memory after power up.
Workaround
For customers concerned by the confidentiality of their firmware, it is recommended to use the RDP Level 2 protection.

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

Итоги: с железом все нормально; не надо лочить контроллер под отладчиком, если не планируется передернуть питание или перезагрузить байты опций.

[makc 217]

10 минут назад, Arlleex сказал:

Главное тут то, что при системном сбросе не сбрасывается отладочная логика, в отличие от сброса по питанию.

Это логично и подтверждается экспериментами. Но собственно к этому сбросу и нет никаких претензий, вопрос именно в сбросе ядра МК и связанной с ним логики.

12 минут назад, Arlleex сказал:

Как мне кажется, OBL_LAUNCH внутренне является системным сбросом, но до входа на "ИЛИ" ответвляется на сброс отладочной логики

Кстати именно эта картинка и наводит на мысль, что реальность далека от изображенного на ней. Ведь при блокировке NRST мы всё же имеем сброс через "Option byte loader reset", т.е. этот ресет ответвляется всё же не на отладочную логику, а уходит через внутренний логический элемент ИЛИ на системный ресет. По-другому я не вижу как можно объяснить наблюдаемые эффекты.

15 минут назад, Arlleex сказал:

Еще, кстати, Errata подталкивает на мысль, что у них там есть какая-то логика при сбросе, которая определяет уровень доступа отладчика

По логике вещей доступ отладчика должен быть запрещен до момента чтения option bytes и определения уровня защиты, в противном случае будет как раз как у них и получилось. Хотя однозначно судить об этом сложно, т.к. перед нами черный ящик с загадочным поведением. ;-)

21 минуту назад, Arlleex сказал:

Итоги: с железом все нормально; не надо лочить контроллер под отладчиком, если не планируется передернуть питание или перезагрузить байты опций.

Я все же не могу согласиться, что с железом всё нормально, т.к. присутствует недокументированная возможность попадания в состояние, при котором NRST не работает со всеми вытекающими отсюда последствиями. Если предположить, что такая возможность определяется каким-то "зарезервированным" битом в одном из системных регистров, то МК может попасть в такое же состояние при наличии ошибки в программе, от которых никто не застрахован и никакой внешний WDT не поможет.

[MrBearManul 0]

38 минут назад, Arlleex сказал:

В новых TRM на Cortex-Mx этого не пишут,

Что печально, подобное не описано и в полном документе на микроархитектуру: ARMv6-M Architecture Reference Manual...

26 минут назад, makc сказал:

и никакой внешний WDT не поможет.

Ага!

51 минуту назад, Arlleex сказал:

Вообще говоря, архитектура Cortex-Mx разделяет типы сбросов на сброс по питанию, системный сброс и сброс отладчика.

Простите, это следует из документа на CM3? Не может быть так, что CM0 по-другому устроен?

[Arlleex 173]

1 час назад, MrBearManul сказал:

Простите, это следует из документа на CM3? Не может быть так, что CM0 по-другому устроен?

Не думаю, что там в этом плане что-то глобально изменилось. Я наблюдаю это поведение на разных МК серий STM32F0/1/2/4. А ядра там - разные.
 

1 час назад, makc сказал:

...и никакой внешний WDT не поможет.

В RM насчет RDP Level > 0 при подключенном отладчике ходят вокруг да около раз 10. Документация на ядро говорит, что при системном сбросе некоторые компоненты отладки не сбрасываются. Если совокупить эту информацию, то приходим к выводу, что при сбросе МК ему надо как-то понимать, защищаться от чтения Flash отладчиком или нет. Разумеется, если системный сброс не затрагивает отладчик (а на момент активации механизма защиты Flash он должен быть отключен), то надо как-то привести систему в состояние, когда отладчик 100% будет отключен - а это только сброс по питанию или иной механизм, сбрасывающий и систему (ядро, периферию и т.д.), и компоненты отладки.

Поэтому я считаю, что WDT еще как поможет, потому что девайс в поле заказчика работает не под отладчиком.

[MrBearManul 0]

22 минуты назад, Arlleex сказал:

Разумеется, если системный сброс не затрагивает отладчик

Гм... а тут мы приходим плавно к тому, что отладка на столе может потребовать передёргивания питания... Или я не прав? У меня J-Link дёргает ножку сбраса.

[makc 217]

14 минут назад, Arlleex сказал:

Разумеется, если системный сброс не затрагивает отладчик (а на момент активации механизма защиты Flash он должен быть отключен), то надо как-то привести систему в состояние, когда отладчик 100% будет отключен - а это только сброс по питанию или иной механизм, сбрасывающий и компоненты отладки.

Вопрос не в отладчике, вопрос в сбросе ядра. Ядро остаётся жить как жило, т.к. NRST не доходит.

20 минут назад, Arlleex сказал:

Поэтому я считаю, что WDT еще как поможет, потому что девайс в поле у заказчиков работает не под отладчиком.

Если мы пока не нашли способа вогнать МК в такое состояние без отладчика, то это еще не значит что его нет. И значит чувствовать себя спокойно на все 100% нельзя.

[Arlleex 173]

2 минуты назад, MrBearManul сказал:

Гм... а тут мы приходим плавно к тому, что отладка на столе может потребовать передёргивания питания...

Если отладка на столе затрагивает режимы защиты Flash, то да, потребует передергивать питание. О чем и прямо написано в RM в нескольких местах.

[makc 217]

6 минут назад, MrBearManul сказал:

Гм... а тут мы приходим плавно к тому, что отладка на столе может потребовать передёргивания питания... Или я не прав? У меня J-Link дёргает ножку сбраса.

Собственно с этим я и столкнулся после перепрошивки, перед которой я сделал unlock, который ничего не дал. Пришлось дергать питанием. Но оказалось, что и lock тоже не отрабатывает, только после передергивания питания. В итоге нашлось решение с описанным выше битом во FLASH_CR.

2 минуты назад, Arlleex сказал:

Если отладка на столе затрагивает режимы защиты Flash, то да, потребует передергивать питание. О чем и прямо написано в RM в нескольких местах.

RM забывает сказать о том, что OBL_LAUNCH помогает решить эту проблему. ;-)

[Arlleex 173]

14 минут назад, makc сказал:

Вопрос не в отладчике, вопрос в сбросе ядра. Ядро остаётся жить как жило, т.к. NRST не доходит.

В смысле ядро остается жить как жило? Т.е. программа запускается и работает?

Я, например, прошиваю блинкер в отладку. Мигает. Иду в ST-Link Utility, захожу в Option Bytes. В этот момент не мигает. Устанавливаю RDP Level 1 и отладчик отваливается от МК, что логично. Не мигает. Жму кнопку сброса - не мигает. Что угодно делай - не мигает. Сбрасываем по питанию - начинает работать и на внешний сброс реагировать. А если зайти теперь в ST-Link Utility и попробовать прочитать регистры ядра - утилита пишет, мол, Flash защищена, но на тебе регистры - выплевывает Lockup-состояние ядра, что, собственно говоря, тоже логично: защита от чтения активна, при подключении делали сброс, при сбросе увидели подключенный отладчик - вот оно, состояние блокировки. И жми кнопку сброса сколько хочешь - отладчик останется подключенным в регистрах, МК же будет при старте входить в состояние блокировки, мигать не будет.

[makc 217]

12 минут назад, Arlleex сказал:

В смысле ядро остается жить как жило? Т.е. программа запускается и работает?

Ядро находится в состоянии HardFault и это состояние перманентно, т.к. NRST не доходит.

14 минут назад, Arlleex сказал:

И жми кнопку сброса сколько хочешь - отладчик останется подключенным в регистрах, МК же будет при старте входить в состояние блокировки, мигать не будет.

На уровне RDP 1 подключение отладчика роли не играет, если он не пытается читать flash. Если пытается считать flash, то получаем HardFault и побочно блокировку NRST. Поэтому само по себе подключение отладчика роли не играет, на сколько я это понимаю.

[Arlleex 173]

8 минут назад, makc сказал:

Ядро находится в состоянии HardFault и это состояние перманентно, т.к. NRST не доходит.

Могу ошибаться, но именно при сбросе, если RDP Level > 0, отладчик подключен и загрузка из Flash, то получим не HardFault, а именно Lockup-состояние. Хотя, может, сначала HardFault, а потом Lockup. По крайней мере, PC равный 0xFFFFFFFE говорит об этом. Интересно бы пробросить какой-нибудь сигнал из обработчика HardFault, будет выполняться или все-таки там Lockup?

[makc 217]

Скорее всего там сразу lockup, т.к. у меня в прошивке есть выдача сообщения в HardFault, но я её ни разу не видел.