stm32 NVIC: сброс маскировки прерываний внутри обработчика Опции

[jeka]

Назрела необходимость (уже давно), разрешить прерывания более низкого приоритета в обработчике высокого приоритета. Способ в лоб - подкорректировав стек и сделать фиктивный возврат из прерывания.
С помощью MRS/MSR как я понял этого не сделать - в документации написано что запись в IPSR игнорируется.
Есть ли какое-то более человеческое решение чем через формирование стека возврата и возврат из прерывания?

Собственно, зачем это нужно - в случае аварии вызывается определенный irq. В обработчике нужно сделать некую аварийную последовательность действий, но для этого нужны рабочие обработчики другиз, в т.ч. низкоприоритетных прерываний. Можно конечно приоритеты нужных irq повысить.
Но есть вторая задача - сделать софтовый ресет (разумеется с обнулением стека), в нужную функцию и с разблокированными прерываниями. Например, в bootolader для перепрошивки.

[jeka]

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

Никто уровни и очереди не правит. Еще раз - задача выполнить reset, но не всего и сразу, а выборочный. Включая сброс NVIC. Чтобы часть периферии и данных в RAM остались нетронутыми.

Чтобы не ресетить девайс - нужно изначально закладывать архитектуру здоровой OS

Вы эту ОС будете переустанавливать/обновлять без ресета?
Действия при аварии электропитания тоже предполагаются без ресета?

[LightElf]

Чтобы часть периферии и данных в RAM остались нетронутыми.

Дык не трогайте данные в RAM - они и останутся нетронутыми. Ресет содержимое SRAM не затрагивает. Для пущей безопасности нужный кусок SRAM защитите CRC или еще каким образом.

[jcxz]

Ресет содержимое SRAM не затрагивает.

Да ладно??! А код boot-ROM, выполняемый после сброса, где стек и рабочие переменные размещает?

[Forger]

Да ладно??! А код boot-ROM, выполняемый после сброса, где стек и рабочие переменные размещает?

В STM32 SRAM не страдает от сброса (кроме, разумеется, сброса от передергивания питания, после которого там всегда будет "мусор").
STM32 RAM behavior after soft-reset


зы Помню, что как-то давно я все недоумевал, зачем в STM32 есть boot-режим старта прямо из ОЗУ (соотв. ремап вектора сброса на начало ОЗУ)? ...

[jcxz]

В STM32 SRAM не страдает от сброса (кроме, разумеется, сброса от передергивания питания, после которого там всегда будет "мусор").

Да ладно?!! Они умудрились написать код чисто на регистрах и без использования стека??? Прямо чудеса чудесатые какие-то рассказываете.....
Или они стек boot-ROM-а научились размещать в облаке?

[Forger]

Да ладно?!! Они умудрились написать код чисто на регистрах и без использования стека??? Прямо чудеса чудесатые какие-то рассказываете.....

Вы ничего не путаете?

В STM32 есть два спец пина BOOT0 и BOOT1, оменно они определяют кто будет запускаться при старте проца:
user-код (User Flash memory), boot-загручик (System memory), ОЗУ или еще что-то (например, в "толстых" камнях).
Опрос этих пинов производится ядром (или узлом, который отвечает за выбор области загрузки) в течение нескольких тактов после сброса.
Но даже в случае безусловного использования бут-загручика можно выяснить области ОЗУ, которые он использует. А используют они совсем небольшую часть ОЗУ.
Это не секретная информация Все есть в соотв. мануалах ))

Еще раз: BOOT-загрузчик в STM32 НЕ стартует безусловно.
Более того, в тотально залоченном состоянии бут вообще невозможно запустить (разве что прочитать его версию):
When readout protection Level2 is activated, STM32 does not boot on system memory in
any case and Bootloader can't be executed (unless jumping to it from Flash user code, all
commands are not accessible except Get, GetID, and GetVersion).


Может, вы путаете STM32 с другими камнями (которые без своей FLASH), где BOOT стартует ВСЕГДА после сброса?

[jcxz]

STM32 does not boot on system memory in any case and Bootloader can't be executed

boot / не-boot - вопрос не в том, что в конце-концов стартует, а в том - какая ОЗУ портится при старте.

[Forger]

boot / не-boot - вопрос не в том,

Вопрос был как раз именно "в том":

Да ладно?!! Они умудрились написать код чисто на регистрах и без использования стека??? Прямо чудеса чудесатые какие-то рассказываете.....

Чудес не бывает, но бывает недостаточно внимательное чтение мануалов

...а в том - какая ОЗУ портится при старте.

Дык, если сам user-код гадит под себя портит ОЗУ, то все вопросы к этому самому коду!
Но это РЕШАЕМО (способов несколько).

[jcxz]

Дык, если сам user-код гадит под себя портит ОЗУ, то все вопросы к этому самому коду!

Вопрос не про пользовательский код. А именно про boot-ROM. И в каких случаях и где он портит.

Вы не со мной спорите, а с мануалом от ST. Имхо, это бессмысленно

Я не спорю с мануалом. Выдержку из него я привёл выше. В которой указывается, что "8 Kbyte starting from address 0x20000000 are used by the bootloader firmware".
Как там написано, так и читаю. К тому же там сказано про бутлоадер версии v7, а какой у меня - не знаю.

[LightElf]

Вопрос не про пользовательский код. А именно про boot-ROM. И в каких случаях и где он портит.

Предположим, что бут-код стартует всегда и выбор режима дальнейшей работы осуществляется программно (тем более что у STM32F042 это именно так). что мешает осуществить эту проверку без стека и переменных? Это же буквально десяток асмовых команд (кстати, латч ножек Boot на 4 такт sysclk какбэ намекает). В общем не буду толочь воду в ступе - на всех виденных мной STM32 содержимое SRAM полностью сохраняется при сбросе, если ножками/фьюзами выбрана загрузка из флеша.

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

Достаточно стертого вектора reset

Сообщение отредактировал LightElf - Aug 3 2017, 09:31

[Forger]

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

Предполагать бессмысленно, все факты описаны в даташитах - выбор места старта выбирается неким аппаратным узлом, который НЕ является частью заводского бутзагрузчика.
Это по сути простейший автомат состояний, который размещен прямо на кристалле, он совсем крохотный, поэтому встроен в каждый STM, отключить его нельзя (а смысл?).
Он лишь, так сказать, "корректирует" вектор сброса перед запуском ядра.

В общем не буду толочь воду в ступе - на всех виденных мной STM32 содержимое SRAM полностью сохраняется при сбросе, если ножками/фьюзами выбрана загрузка из флеша.

Именно!
Более того, в SRAM судя по всему нет аппаратного сброса, поскольку, судя по даташитам, после подачи питания там "мусор".

Достаточно стертого вектора reset

Есть такое, вот тут нашел подтверждение:

Empty check (category 1 devices only)
On category 1 devices, an internal empty check flag is implemented to allow easy
programming of virgin devices by the bootloader. This flag is used when BOOT0 pin is
configured to select Flash program memory as target boot area. When this flag is set, the
device is considered as unprogrammed and the system memory (bootloader) is selected as
boot area instead of the Flash program memory to allow the application to program the
Flash memory.
The empty check flag is updated only when the option bytes are loaded: it is set when the
content of address 0x8000 0000 is read as 0x0000 0000 and cleared otherwise. As a result,
only a power-on reset or setting OBL_LAUNCH bit in FLASH_CR register can clear this flag
after programming a virgin device to execute user code after system reset.

Но этот флажок реализован не во всех STM32, в "старых" семействах, увы, он не реализован ((

[LightElf]

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

Действительно, бессмысленно предполагать. Надо тупо залезть дизасмом в бут и посмотреть

[AVI-crak]

Действительно, бессмысленно предполагать. Надо тупо залезть дизасмом в бут и посмотреть

КАК?
Каким образом смотреть содержимое ядра и адресного пространства мк в режиме явного срабатывания загрузчика по usart???
Вопрос на миллион баксов!!!

[jcxz]

Каким образом смотреть содержимое ядра и адресного пространства мк в режиме явного срабатывания загрузчика по usart???
Вопрос на миллион баксов!!!

Очевидно: подключиться стандартно эмулятором и с помощью него запустить код UART-загрузчика из ROM?
Или что имелось в виду?

[LightElf]

Очевидно: подключиться стандартно эмулятором и с помощью него запустить код UART-загрузчика из ROM?
Или что имелось в виду?

Имелось в виду слить дамп памяти встроенного бутлодера и дизассемблировать его. Дабы подтвердить/опровергнуть предположение о программном характере выбора пути загрузки.
Посмотрел бут F030 - обращений к регистру конфигурации не увидел. Указатель стека сразу же указывает в RAM, но вначале достаточно долго RAM не портится - идет куча действий строго на регистрах.

[Forger]

Дабы подтвердить/опровергнуть предположение о программном характере выбора пути загрузки.

Встроенный загрузчик STM (размещен в System Memory) не участвует в принятии решения кто будет работать, т.к. он сам является частью выбора.
Он запускается после принятия решения. Я лично в этом убедился, о чем выше написал и привел скриншот.

[LightElf]

Встроенный загрузчик STM (размещен в System Memory) не участвует в принятии решения кто будет работать, т.к. он сам является частью выбора.
Он запускается после принятия решения. Я лично в этом убедился, о чем выше написал и привел скриншот.

Знаете что самое смешное? Что вы скорее всего правы, но аргументация ваша никакой критики не выдерживает.
Ну что за бред: "не участвует в принятии решения кто будет работать, т.к. он сам является частью выбора"? Какая логическая конструкция запрещает выбирать, в том числе, и из себя?
Точка останова на первой команде, расположенной в масочном ПЗУ - тоже ничего особо не доказывает. Совсем не факт, что дебаговый модуль и используемые для отладки пины включены сразу.
Микроконтроллеров, у которых пины JTAG настраиваются встроенным загрузчиком, чуть менее чем дофига.

[Forger]

Знаете что самое смешное? Что вы скорее всего правы,

Не вижу ничего смешного при работе с фактами, которые описаны в даташитах!

но аргументация ваша никакой критики не выдерживает.

Коли я прав, но моя аргументация вам не нравиться, так приведите свою, основанную на фактах, а не на домыслах и предположениях.

Точка останова на первой команде, расположенной в масочном ПЗУ - тоже ничего особо не доказывает.

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

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

Факт - пины JTAG доступны лишь при разлоченном проце (Level 1 или Level 0). В режиме Level 2 отладка навсегда заблокирована, снять блокировку нельзя.
Факт - на тотально залоченном проце (Level 2) бут-загрузчик при старте НИКОГДА НЕ запускается, о чем указано в датишите.
Факт из даташита (цитирую еще раз):
When readout protection Level2 is activated, STM32 does not boot on system memory in any case and
Bootloader can't be executed (unless jumping to it from Flash user code, all commands are not accessible except Get, GetID, and GetVersion).
Это говорит о том, что узел, определяющий кто может работать а кто нет - вначале ориентируется на Option Bytes и состояние пинов BOOT.
Не так уж и сложно сделать железобетонный автомат на логике, который все это делает без всяких микропрограмм и скрытых бут-загручиков.
Впрочем, как именно это сделано, нигде не описано. А причины просты - дабы не открыть секретную информацию по тому, как вскрыть залоченный проц.

Факт: в даташите указано, что запускается ИЛИ system memory со своим бутзагрузчиком ИЛИ flash memory с вашей прошивкой. ИЛИ/ИЛИ. Никаких других вариантов не указано.
Факт: загрузчик из System Memory запускается безусловно только в случае полностью стертого проца и то не в самых старых семействах ST.
В всех остальных случаях перед запуском бут-загрузчика производится анализ состояния пинов BOOT и в некоторых STM определенных регистров из Option области.

Обратите внимание, я привел факты.

Микроконтроллеров, у которых пины JTAG настраиваются встроенным загрузчиком, чуть менее чем дофига.

Мы говорим про конкретное семейство МК - STM32. Предлагаю не отвлекаться.

Короче, если найдете хоть какую-то новую информацию по работе узла запуска/загрузки STM, выкладывайте сюда. Со ссылками.

[LightElf]

Не вижу ничего смешного при работе с фактами, которые описаны в даташитах!

Ошибкой является принимать свою трактовку расплывчатых слова из даташита за факты.
Ну и вообще, даташиты очень часто многое умалчивают. Например даташит на STM32F101 умалчивает о наличии в на кристалле USB Device контроллера и нескольких лишних десятков килобайт FLASH.

Коли я прав, но моя аргументация вам не нравиться, так приведите свою, основанную на фактах, а не на домыслах и предположениях.

Да, мне не нравится отсутствие логики на техническом форуме.
В даташите описано конечное поведение микроконтроллера, а не способ реализации такого поведения. Наличие некой аппаратной схемы, которая там чего-то куда-то переключает в зависимости от состояния ножек и option bytes - это сугубо ваши домыслы, в даташите же ничего на эту тему не сказано.

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

Религию себе придумали вы и как раз вы и пытаетесь распространять свою веру, причем довольно агрессивно и напористо. Я же, всего-лишь навсего, утверждаю что в даташите вообще нет никакой информации о том, как именно обсуждаемый функционал реализован.

Факт - пины JTAG доступны лишь при разлоченном проце (Level 1 или Level 0). В режиме Level 2 отладка навсегда заблокирована, снять блокировку нельзя.
Факт - на тотально залоченном проце (Level 2) бут-загрузчик при старте НИКОГДА НЕ запускается, о чем указано в датишите.

В даташите указано, что к залоченному чипу нельзя достучаться снаружи через интерфейс загрузчика или отладочный порт. Все. Чего там внутри запускается или не запускается - не описано.

Факт из даташита (цитирую еще раз):
When readout protection Level2 is activated, STM32 does not boot on system memory in any case and
Bootloader can't be executed (unless jumping to it from Flash user code, all commands are not accessible except Get, GetID, and GetVersion).
Это говорит о том, что узел, определяющий кто может работать а кто нет - вначале ориентируется на Option Bytes и состояние пинов BOOT.

Это не говорит абсолютно ни о чем.

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

Не сложно, главное верить.

Факт: в даташите указано, что запускается ИЛИ system memory со своим бутзагрузчиком ИЛИ flash memory с вашей прошивкой. ИЛИ/ИЛИ. Никаких других вариантов не указано.

А что, возможен вариант И/И? Ну и зачем производителю расписывать свою внутреннюю кухню, если потребителю от этого не холодно и не жарко?

Факт: загрузчик из System Memory запускается безусловно только в случае полностью стертого проца и то не в самых старых семействах ST.

Неправда, причем в данном случае прямо противоречащая даташиту. Вполне определенно сказано, что проверяется адрес 0x08000000 на равенство 0xFFFFFFFF.

Обратите внимание, я привел факты.

Нет. Вы привели цитаты из даташита и придумали им свои трактовки.

Короче, если найдете хоть какую-то новую информацию по работе узла запуска/загрузки STM, выкладывайте сюда. Со ссылками.

Щаз, штаны подтяну и ломанусь искать опровержения вашим выдумкам.

[Forger]

А что, возможен вариант И/И?

В фантастических книжках, конечно, возможен, но в реальности (в т. ч. в даташитах) пока что только ИЛИ

Если вы утверждаете, что загрузчик из System Memory стартует всегда и безусловно, несмотря на то, что в даташитах указано обратное,
то объясните эту цитату, которая есть в полном даташите на любой STM:

The boot mode configuration is also re-sampled when exiting from Standby mode.
Consequently they must be kept in the required Boot mode configuration in Standby mode.

Или вы веруете считаете, что во всех STM существует некий "секретный бут-загрузчик", который нигде не описан и который не имеет никакого отношения к официальному загрузчику из System Memory?
Я правильно понял?

[LightElf]

Если вы утверждаете, что загрузчик из System Memory стартует всегда и безусловно, несмотря на то, что в даташитах указано обратное,

И где же там указано "обратное"?

то объясните эту цитату, которая есть в полном даташите на любой STM:

А что именно вызывает затруднения в понимании? При выходе из Standby фактически происходит полная реинициализация процессора (кроме Backup домена). Видимо при этом отрабатывается ровно та же процедура, что и при PowerOn.

Или вы веруете считаете, что во всех STM существует некий "секретный бут-загрузчик", который нигде не описан и который не имеет никакого отношения к официальному загрузчику из System Memory?
Я правильно понял?

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

На закуску читаем RM0090:

To select boot from Flash memory bank 2, set the BFB2 bit in the user option bytes. When
this bit is set and the boot pins are in the boot from main Flash memory configuration, the
device boots from system memory, and the boot loader jumps to execute the user
application programmed in Flash memory bank 2.

[Forger]

И где же там указано "обратное"?

Мля, да в любом полном даташите на ЛЮБОЙ STM32 в соотв. табличке указаны варианты исключительно ИЛИ:

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

Я лично убедился под внешним сторонним отладчиком, что при конфигурации старта из System Memory, запускается системный бут-загрузчик строго с того адреса, где он указан в даташите.
Если же запускается некий "секретный загрузчик" до передачи управления в System Memory или Main Flash, то он не имеет никакого отношения к УСЛОВНО запускаемому загрузчику из System Memory.

Ваша святая вера в "секретную схему" ни на чем не основана.

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

Однако, как я понял, вы упорно верите в то, что загрузчик из System Memory стартует ВСЕГДА БЕЗУСЛОВНО несмотря на то, что в даташитах указан его УСЛОВНЫЙ старт .
А коли так, то предлагаю на этом поставить точку, ибо иначе это все, просто, перерастет в некую фантастику, религию и т. п.

[LightElf]

Мля, да в любом полном даташите на ЛЮБОЙ STM32 в соотв. табличке указаны варианты исключительно ИЛИ:

Я из этой таблички делаю вывод, что управление будет, в конце концов, передано в системный загрузчик или в пользовательскую прошивку - что мы собственно и наблюдаем вживую. Передано ли туда сразу (первой исполняемой командой процессора) или по результату исполнения некоего первоначального кода - из таблички никак не следует и уверенно сказать об этом нельзя.

Я лично убедился под внешним сторонним отладчиком, что при конфигурации старта из System Memory, запускается системный бут-загрузчик строго с того адреса, где он указан в даташите.
Если же запускается некий "секретный загрузчик" до передачи управления в System Memory или Main Flash, то он не имеет никакого отношения к УСЛОВНО запускаемому загрузчику из System Memory.

Я убедился путем дизассемблирования, что в STM32F030 в системной памяти нет команд, определяющих вариант загрузки. Но:
1) "секретный загрузчик" может быть и в другом месте
2) В других камнях STM32 может быть по-другому. Как минимум у STM32F042 отличия должны быть.

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

Это не вопрос веры, это вопрос неверия. У нас нет достоверной информации о том как это реализовано. Может быть так, может быть эдак, может быть еще каким-то третим способом. Но вы упорно настаиваете на одном конкретном варианте, непонятно на каком основании. Аппаратное решение совсем не проще в реализации и уж явно не гибче. Ежели какая-нибудь бага обнаруживается, то проще изменить заливаемый на конвейере код загрузчика, чем вносить изменения в маски.

Однако, как я понял, вы упорно верите в то, что загрузчик из System Memory стартует ВСЕГДА БЕЗУСЛОВНО несмотря на то, что в даташитах указан его УСЛОВНЫЙ старт .
А коли так, то предлагаю на этом поставить точку, ибо иначе это все, просто, перерастет в некую фантастику, религию и т. п.

Я уверен (и Reference Manual на STM32F4xx это подтверждает), что как минимум у ряда контроллеров из семейства STM32 код системной области (не буду называть его загрузчиком дабы избежать путаницы) принимает участие в выборе режима старта.

[Forger]

что мы собственно и наблюдаем вживую.

Алилуйя! Наконец-то мои слова услышаны!
Камень ведет себя именно так, как описано в даташите. Встроенный загрузчик запускается точно также условно, равно как и пользовательский код.
А вы пытались с этим спорить... Смысл?

Я убедился путем дизассемблирования, что в STM32F030 в системной памяти нет команд, определяющих вариант загрузки.

Ура!

1) "секретный загрузчик" может быть и в другом месте

Точно также он может быть лишь в фантазиях того, кто его выдумал

У нас нет достоверной информации о том как это реализовано. Может быть так, может быть эдак, может быть еще каким-то третим способом.

Вот, вы меня уже цитируете

Но вы упорно настаиваете на одном конкретном варианте, непонятно на каком основании.

Читайте внимательнее:
Я настаиваю совсем на другом - чтобы вы не путали встроенный штатный бутзагрузчик с неким своим вымышленным "секретным" загрузчиком.

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

Весьма спорное утверждение - камни на заводе не прошивают, как вам это может показаться. Тестируют кристаллы прямо на пластине, причем, наверняка выборочно.
Бут-загрузчик у STM находится не во FLASH, а в некой ROM, она обходится дешевле FLASH.
Эта ROM не прошивается, а формируется сразу на этапе производства масок для процессов литографии и т. п.
Т.е. для смены версии загрузчика меняется целиком весь кристалл заодно с исправлениями ядра/периферии, а отдельно перешивать уже изготовленные камни никто не будет - это абсолютно невыгодно.

Для примера - если в печатной плате есть некритичный косяк, то такие косяки "накапливают" с другими и выпускают новую версию платы, где эти косяки исправлены ВСЕ ВМЕСТЕ.
Никто не будет по-настоящему серийные платы вручную дорабатывать, т. к. их намного выгоднее списать и сделать новые правильные.
А в случае микросхем зачастую выгоднее выпустить еррату и "собирать косяки" на новую версию камню. Чем толще еррата, тем более скупой производитель процов
Не стоит путать реально мега-массовое про-во со штучными "гаражными" поделками!

Я уверен (и Reference Manual на STM32F4xx это подтверждает), что как минимум у ряда контроллеров из семейства STM32 код системной области (не буду называть его загрузчиком дабы избежать путаницы) принимает участие в выборе режима старта.

Дык, если это указано в даташите на этот камень, то так одно и должно быть. Уверен, что под отладчиком это будет полностью подтверждено. Я с этим не спорил и не спорю ))
Речь-то совсем о другом - о том, что не описано ни в одном официальном даташите и никак не выясняется под отладчиком.
Этот "аппаратный узел" / "секретный загручик" не имеет никакого отношения к штатному загрузчику из System memory, он не является его частью, что подтверждают даташиты и отладчик.
С самого начала именно это я и пытался донести.
Теперь-то, надеюсь, все прояснилось?