Перейти к содержанию
    

Запрещение и разрешение прерываний

Это уже было. Прерывание между этими двумя командами может изменить CPSR

 

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

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Зато между

prim = __get_PRIMASK();

и

__disable_irq();

вполне могут быть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

prim = __get_PRIMASK();
__disable_irq();

Это уже было. Прерывание между этими двумя командами может изменить CPSR

..то при возникновении прерывания между этими двумя командами (а оно может изменить параметры прерываний)

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

 

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

 

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

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

Изменено пользователем GetSmart

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Зато между

prim = __get_PRIMASK();

и

__disable_irq();

вполне могут быть.

 

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

 

 

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Бред какой-то.

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

Изменено пользователем GetSmart

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может потому, что они не пытаются разрешать/запрещать прерывания из обработчиков этих самых прерываний? Интересно, зачем такое может понадобиться?

 

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

 

Нет, не оно. Эта функция сначала считывает CPSR в регистр, меняет биты в регистре, потом заносит регистр в CPSR. Если в это время произойдет прерываие и CPSR будет изменен - будет плохо.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я сгенерировал кубом код для STM32F429 и добавляю в него необходимые мне функции.

В этом и есть основная проблема. Код для прерывания необходимо писать самому, с минимальным использованием внешних данных.

Сами функции в такой системе делятся на два типа - имеющие зависимости и без них.

 

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

 

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

 

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

Изменено пользователем GetSmart

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

Изменено пользователем GetSmart

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...