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

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

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

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

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


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

Ядро/тактовые генераторы и пр. изначально не остановлены. Иначе пользовательское ПО вообще не могло бы запуститься.


Это всего лишь логика.
Если к примеру на плате Вашего устройства уже стоит МК и вдруг появляется дополнительная необходимость - при включении питания платы (МК) пискнуть в динамик. Вы поставите дополнительную FPGA, на которой будете реализовывать генератор? Или всё-таки задействуете одну из ног существующего МК и напишете простенький цикл в начале ПО?

В режим standby тактирование ядра отключено, но при выходе из этого режима производится повторный опрос входов BOOT, это описано в даташите.
Что говорит о том, что опрос пинов BOOT производится аппаратно, но не программно неким мифическим скрытым загрузчиком. Это факт.

Это всего лишь демагогия. Факты в студию - факты!

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

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

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

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


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


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


Факт - пины 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 области.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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




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


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

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

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

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

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

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

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

Ура!


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


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

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


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

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

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

Итоговое поведение процессора соответствует даташиту. Как именно это реализовано - по-прежнему неизвестно.

Читайте внимательнее: у STM32F42x это один блок кода.

К счастью, в ST идиотов мало сидят достаточно умные люди, чтобы не пытаться вышеуказанную чушь реализовывать. Потому бутлоадер размещают в самом обычном флеше и прошивают его в процессе производства. Что позволяет не только менять заливаемую версию бутлодера без изменения масок, но и складывать туда Unique ID, калибровки температурного датчика и тактового генератора, уникальные для каждого кристалла. О чем, совершенно не скрываясь, пишут в своих даташитах.

Маску наверно под каждый кристалл переделывают, угу.

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

Вы специалист по мега-массовому производству или из гаража разъяснения даете? Сколько миллионов изделий произвели?

Учебник логики купите. Может поймете, чем "отсутствие доказательства явления" отличается от "доказательства отсутствия явления".

Сообщение отредактировал LightElf - Aug 30 2017, 08:41