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???
Вопрос на миллион баксов!!!

[LightElf]

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

Не понял вопроса. Код бутлодера доступен для чтения всегда (если камень не залочен).

Если уже и даташитам веры нет (тотальный атеист), то придется назначение регистров также "проверять дизасмом" ....

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

[Forger]

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

Явно слова hardware там не указано, но вы внимательнее почитайте про принцип выбора вектора сброса.
Более того, в даташитах явно указано, после выхода из standby режима повторно производится опрос пинов boot (это указано в даташитах), а уж это явно сделано аппаратно.
Ну, и как минимум то, что управление передается заводскому загрузчику по точно такому же принципу, как и юзер-коду,
наводит на мысль, что выбор вектора сброса производится где-то в недрах камня, про детальную работу которого нигде нет информации.
Если вам удастся найти эту информацию, поделитесь с нами

На мой взгляд - это нелогично.

Это еще почему?
По-мне - как раз существующее исполнение вполне логично.

[LightElf]

Это еще почему?
По-мне - как раз существующее исполнение вполне логично.

Городить аппаратный блок, уникальный для каждого кристалла и для дальнейшей работы совершенно не нужный, вместо того чтобы добавить пяток команд - это логично?

[jcxz]

Городить аппаратный блок, уникальный для каждого кристалла и для дальнейшей работы совершенно не нужный, вместо того чтобы добавить пяток команд - это логично?

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

[Forger]

Вот именно! Я об этом же и писал - совершенно нелогично. Когда под боком такое мощное ядро.

Этот аппаратный узел позволяет вообще не трогать ядро, ничего не трогать.
Т.е. ядро, периферия, тактовые генераторы и т.п. изначально вообще остановлены.
Причины могут быть разные - борьба за потребление, за надежность да и мало еще за что?!

Короче, не нравится решение ST? Нет проблем - рисуйте свой проц и делайте так, как душе угодно

Скорее всего ST хитрит - скрыли этот код инициализации в недокументированную область.

Уфология прям - зеленых человечков никто не видел, но они есть!