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]

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

В AN2606 в Table 66. STM32F42xxx/43xxx configuration in system memory boot mode указано, что 8 Kbyte starting from address 0x20000000 are used by the bootloader firmware.
И эта область указана как Common to all bootloaders.
Также видно, что указатель стека из вектора сброса из таблицы векторов прерываний в ROM по адресу 0x1FFF0000 (из STM32F429 который у меня сейчас на столе) указывает на адрес 0x20002318 опять-же - внутри этих 8КБ.
Вот именно этот код, который считывает BOOT-пины и определяет куда передать управление (и возможно что-то ещё делает), видимо и находится по адресу, на который указывает вектор сброса из 0x1FFF0000.

PS: Не посчитал однако... 0x20002318 - это ведь уже за пределами 8КБ. Странно....
Опять-же - в AN2606 говорится про Bootloader V7.x. А какая у моего версия - не знаю.

[Forger]

В AN2606 в Table 66. STM32F42xxx/43xxx configuration in system memory boot mode указано, что 8 Kbyte starting from address 0x20000000 are used by the bootloader firmware.
И эта область указана как Common to all bootloaders.
Также видно, что указатель стека из вектора сброса из таблицы векторов прерываний в ROM по адресу 0x1FFF0000 (из STM32F429 который у меня сейчас на столе) указывает на адрес 0x20002318 опять-же - внутри этих 8КБ.

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

Вот именно этот код, который считывает BOOT-пины и определяет куда передать управление (и возможно что-то ещё делает), видимо и находится по адресу, на который указывает вектор сброса из 0x1FFF0000.

Вы не понимате )))
Нету никакого кода, который якобы считывает эти два пина. Это все сделано аппаратно. И происходит это в первые 4 такта проца после сброса.
Это указано в мануале на каждый проц: The boot mode configuration is latched on the 4th rising edge of SYSCLK after a reset. It is up to the user to set boot mode configuration related to the required boot mode.
Даже если бы эти пины опрашивались в неком коде, то даже гипотетически невозможно создать такой код, который бы за 4 такта умудрился проинитить хотя бы стек, настроить пару пинов и прочитать их содержимое


Кстати, вот это только что выяснил: The boot mode configuration is also re-sampled when exiting from Standby mode, на будущее надо учесть!