Между какими командами? После FAULTMASK=1 прерываний не будет...

Зато между
prim = __get_PRIMASK();
и
__disable_irq();
вполне могут быть.

Может быть PSR? Судя по мануалам, первая команда не обращается к PSR, а вторая здесь не ясна. Если она сделана через cpsid i, то тоже не обращается. У СМ3/CM4 (и возможно в CM7) в PSR есть поля, относящиеся к обработке условного префикса IT. Если они меняются, то так и пишите, т.к. это не "параметры прерываний".

Из прерываний/исключений можно выйти с намеренно искажённым PSR. И после выхода там будет не то, что было на точке прерывания предыдущего уровня. Только это не должно влиять на правила осторожности предыдущего уровня.


Пока описана только гипотеза. Некорректное поведение процессора не описано.

Сообщение отредактировал GetSmart - Jan 26 2016, 22:35

Откуда они возьмутся, если FAULTMASK=1: Prevents the activation of all exceptions except for NMI?




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

Если заменить все 8 слов, которые прерывание сохранило аппаратно, и ещё заменить несохранённые регистры, то при выходе можно переключить прерванный тред. Если есть гарантия, что был прерван именно тред. Соответственно PSR на выходе из прерывания будет абсолютно другой.

Что содержится в IPSR (который является частью PSR) в мануалах написано, а на что оно влияет я не увидел. То бишь зачем оно там.

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

И что? Они точно так же сохранят в себе текущее состояние прерываний и восстановят перед выходом. А иначе ну глупо же получится - работала-работала себе программа, вдруг в производьном ее месте происходит внешнее событие (вызывающее прерывание) и после его обработки дальше программа вдруг дальше (со случайного места!) работает уже с запрещенными прерываниями. Бред какой-то.

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

Сообщение отредактировал GetSmart - Jan 27 2016, 13:01

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

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

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

Отсюда и возникает та проблема, о которой я говорю.

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

Разрешать прерывания изнури обработчика плохая идея.



Почему будет плохо? Ну сходит в прерывание между командами и вернется в том же виде (того кто напишет прерывание, что изменяет CPSR надо канделябром по фаберже), а затем запретит прерывание и продолжит работу.

В этом и есть основная проблема. Код для прерывания необходимо писать самому, с минимальным использованием внешних данных.
Сами функции в такой системе делятся на два типа - имеющие зависимости и без них.

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

Функции без зависимостей - можно применять бесконечное количество раз одновременно, в том числе и в прерываниях. И неважно сколько у неё входных/выходных параметров, и сколько она в себе несёт вторичных вызовов. Всё аккуратно посчитается и вернётся на свои места.

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

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

Это кривой код обработчика прерываний, или код, оттуда вызывающийся. Который должен быть исправлен ТАМ ЖЕ. А не в другом месте программы.

Или хитрая (но ничего не гарантирующая) задумка воздействия на обработку прерываний всей системы. От самого простого предположения: остановить приём всех прерываний до того, как тред не разрешит их снова. Общие критические секции (вставки) в этом случае не должны меняться.

Сообщение отредактировал GetSmart - Jan 28 2016, 00:11

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

Problem: в девайсе что-то глобально запрещает прерывания в абсолютно случайном месте кода.

Workaround: если не известна логика, по которой это происходит, то нет "прямого" решения. Или совсем кривое решение: расставить во множество мест своей программы глобальное разрешение прерываний. Везде, где они должны быть разрешёнными. Это если точно обозначена проблема.

Критические секции тут ни при чём.

Сообщение отредактировал GetSmart - Jan 28 2016, 05:19

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