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

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

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

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

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

Вероятно, имелось ввиду подключиться отладчиком, и смотреть из-под соотв. проги, например, такой: https://www.segger.com/products/debug-probe...er/about-ozone/.
Это вполне реализуемо, если камень не залочен.

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

Я говорю о том, что в момент аппаратного срабатывания триггера выбора загрузочного интерфейса - всё остальное отключается!!!!. Потому как сам механизм записи в память флеша - не имеет арбитра. Да и всего остального фарша - тоже.

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


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

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

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

Так всё-таки: что мешает не срабатывать этот самый триггер, а подключиться как обычно JTAG-ом, найти точку входа в процедуру загрузки по UART (в ROM очевидно) и запустить её ручками?
Может быть конечно, что при подключении JTAG область ROM становится невидимой, но обычно она видна (в тех МК что я видел).

Если камень не залочен, то ВСЕ прекрасно видно, весь камень ))




зы Ради спортивного интереса прям щас принудительно кинул BOOT0 на VDD, подключился через Ozone. Загрузчик тут начинается с 0x1FFFC800 (discovery на базе STM32F072RB, st-link ессно перешит в j-link)
Встроенный бут запускается сразу же после сброса (нажали на кнопку, которая коротит NRST на землю) и тут же останавливается (нужно выбрать режим сброса "Reset & halt").
Т. е. управление СРАЗУ ЖЕ передается в System memory, как и указано в даташите.
Вот картинку сделал:



Кстати, посмотрел на состояние SRAMдо и после аппаратного сброса: не потерлась.
Кроме, конечно тех частей, к которым обращается сам код.

Теперь осталось только обещанный миллион с AVI-crak стрясти! Все свидетели - он обещал

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

Нет, это - не "программный" ресет, это - сброс всего ядра и вообще всего проца (через модуль отладки).
Кстати, программный сброс у STM сделан так, что формирует фактически как и аппаратый сброс (тянет ножку NRST на землю на несколько мкс).
Отличается программный сброс у STM от полного сброса POR (подали питание) разве лишь тем, что содержимое SRAM сохраняется.
Открывайте мануалы, изучайте. Там все про это расписано. Внимательно читайте. Пусть у ST и не самая лучшая документация, но это там точно описано.

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

Короче, если вы ВЕРИТЕ в существование какого-то мифического бут-загрузчика в STM, который всегда безусловано запускается, то это - лично ваше дело, вероисповедание - личное дело каждого.
Но коли речь идет про конкретные физические вещи, созданные обычными людьми, то и правила тут работают соответствующие - факты. Факты я привел.
А домыслы и мифы предлагаю оставить вне этой темы

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

Этот вопрос сразу задавайте в ST. Ваши рекомендации им явно будут очень полезны

Мне же лично решение ST в данном случае кажется вполне логичным.


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