Согласен, я поспешил с выводами
Выходит, что в более приоритетных прерываниях нельзя использовать svc, а можно лишь в задачах/потоках. Этого я не знал ((

Я рассчитывал в реализациях программных очередей (queue) отказаться от критических секций (простое запрет/разрешение прерываний),
но коли в прерываниях это создает трудности (скажем, прерывание от usart), то выходит, что svc ипользовать не получится. А жаль ((
Или можно просто поднять приоритет svc до уровня чуть ниже важных прерываний (в которых запрещены вызовы серсвисов оси), тогда задача решится. Я прав?

Если смотреть по коду, который я привел - первый запрос на эксклюзивный доступ здесь:

второй запрос в обработчике программного прерывания:

Надо только обеспечить, чтобы в любой точке вызова SVC текущий уровень приоритета прерывания был ниже чем у SVC. И были разрешены faults. Тогда не будет HF, а будет корректный вход в ISR SVC.


Можно конечно, но ещё раз спрашиваю: зачем надевать трусы через голову??
Ведь если уж никак нельзя запрещать прерывания, то есть механизм LDREX/STREX, который именно для этого и создан.
А SVC - даже из названия видно - это для вызова системных функций. Привилегированных.
Можно конечно работу с очередями (или что там ещё) вынести на этот уровень, но зачем??? Это будет во много раз медленнее и громоздко чем LDREX/STREX.


А что такое "запрос на эксклюзивный доступ"? Откуда Вы это взяли?? Нет такого понятия. Нет никаких запросов там.
Эксклюзивный доступ read-modify-write - это пара инструкций LDREX/STREX работающих с некоей переменной.
Эксклюзивно - это означает, что никто другой (другой процесс) не обращается к этой переменной между LDREX и STREX. А если это условие нарушается - это нарушение эксклюзивности.
В Вашем случае есть одна только пара LDREX/STREX, её эксклюзивный доступ никто не нарушает.
Похоже Вы совсем не поняли, что написано в мануале и для чего это вообще нужно. Перечитайте ещё раз.

Это решаемо, просто, запрещается вызов SVC в критичных прерываниях, где запрещен вызов сервисов оси (соотв. assert).


Не понял ((( Т.е. запрещенные faults нарушают нормальную работу SVC?

Естественно. Я же писал уже несколько раз:

Ещё раз: если SVC по каким-то причинам не может быть активировано немедленно, будет эскалация до HF.
Считайте что SVC - это вызов функции. Если у Вас в коде идёт команда BL, то ведь процессор обязан её выполнить, он не может её перескочить.
То же самое и с SVC - это считается вызовом системной функции. Она не может быть не выполнена. А если запрещены fault-ы - значит активировать исключение нельзя. Из-за этого конфликта и будет эскалация до HardFault. Процессор будет стоять на SVC и повышать-повышать приоритет её до тех пор, пока не сможет выполнить. Он и повысит до HF, которое может выполнить даже с запрещёнными fault-ами.
Так как это синхронное прерывание, значит оно должно быть выполнено немедленно.

Речь как я понял идет про конкретно один fault - SVCall Handler. Или я опять не так понял?

Попался полезный документ по теме:
http://infocenter.arm.com/help/topic/com.a..._primitives.pdf

Я не претендую на истину в последней инстанции и рассматриваю применение SVC в моих проектах как один из методов программирования с использованием предоставленных возможностей процессора. Ноги где-то растут из старых времен MS DOS и использованием INT 2F .

Как кто-то в теме догадался, не люблю я всякие запреты-разрешения прерываний. Зачем меня должно в участке кода заботить, какие разрешены, а какие нет? Если работать с запретом и последующим разрешением общего прерывания, надо тоже хоть немного контекст сохранять: надо бы знать, а было ли вообще разрешено прерывание на момент необходимости его запрета, чтобы потом не разрешить случаем то, что было запрещено? Затем необходимо множить такие блоки во всех фрагментах, которые критическую секцию используют: хоть макросы напиши, код получается громоздкий для написания и понимания. Не нравится мне это чисто стилистически. На круг получится, что суммарный код обрамления критических секций станет больше обработчика SVC. Синтаксически - как следует из заголовка, который я привел, - я работаю с на вид обычными функциями, которые порождают единственную инструкцию.

И еще. Тут многие забалованы F4xx и выше. А у меня есть проекты на одной плате с опциональными F103 и F051 (ценообразование). Вы будете смеяться, но на Cortex-M0 F051 LDREX/STREX отсутствуют. А механизм SVC работает на обоих.

Сообщение отредактировал KnightIgor - Jun 5 2017, 12:50

например, отсюда:
"PM0214. STM32F3xxx and STM32F4xxx Cortex-M4 programming manual.
2.2.7 Synchronization primitives
...
A pair of synchronization primitives comprises:
● A Load-Exclusive instruction: Used to read the value of a memory location, requesting
exclusive access to that location."


Эта пара нужна, чтобы монитор эксклюзивного доступа отметил выполнение LDREX, затем при выполнении STREX снял эту метку, разумеется при условии, что данной парой LDREX/STREX мы не влезли между LDREX и STREX другой части программы, например в случае возникновения прерывания. Если переписать код следующим образом:

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


В таком случае, если не сложно, приведите, пожалуйста, небольшой пример кода, когда происходит нарушение эксклюзивности.

Бит разрешения на все fault-ы один общий.

Вот тут посмотрите: тынц. И вообще всю тему посмотрите. Там очень подробно всё разобрали, с учётом особенностей STM32.

Я тоже его нашел, сейчас как раз изучаю. Тема также освещена в ARMv7-M Architecture Reference Manual, где среди прочего написано про разделяемую память, про глобальный и локальный мониторы эксклюзивного доступа, многопроцессорность и т.д. Все эти документы ARM-овские.
У ST LDREX/STREX описаны в PM0214. STM32F3xxx and STM32F4xxx Cortex-M4 programming manual. Причем довольно коротко, многое не по какой-то причине не затронуто и даже ссылок на АРМ-овские документы не даны.
В общем, поизучав все это приходит мысль, что я просто в каком-то регистре не поставил какой-то флаг и у меня, например, не работает глобальный монитор.

void f1()
{
CPU_SR_ALLOCATE(); //выделение переменной (регистра) для сохранения состояния прерываний
ENTR_CRT_SECTION(); //вход в критическую секцию (запрет прерываний)
...
EXIT_CRT_SECTION(); //выход из критической секции (восстановление состояния прерываний)
}
void f2()
{
CPU_SR_ALLOCATE(); //выделение переменной (регистра) для сохранения состояния прерываний
ENTR_CRT_SECTION(); //вход в критическую секцию (запрет прерываний)
f1();
...
EXIT_CRT_SECTION(); //выход из критической секции (восстановление состояния прерываний)
f1();
}
Вот и всё отслеживание. Больше никаких проверок не нужно и можно вызывать сколько угодно вложенно - всё работает корректно.
ENTR_CRT_SECTION() - компилится в 2 команды CPU;
EXIT_CRT_SECTION() - компилится в 1 команду CPU.
Теперь сравните со своим огородом в десятки команд.

Ох, ну вот уж проблема так проблема
Это может выглядеть, например, просто как объявление

в начале блока кода. При выходе из блока прерывания автоматически возвращаются в исходное состояние.

Я не говорю, что ваш способ ошибочен, я говорю, что он не даёт преимуществ по сравнению с простым запретом/разрешением прерываний, и к тому же он (гораздо) медленнее. Думаю, что на маленьких процессорах (типа M0(+)) это может быть критично.
Кроме того, как тут выяснили, этот способ требует правильной расстановки приоритетов, а иначе способен вызвать HardFault.

Видимо это какое-то изобретение терминологии деятелей из STM.
Изучать ядро нужно по первоисточнику http://infocenter.arm.com/help/index.jsp, а не по переводам и толкованиям. А в первоисточнике нет никаких "requesting".


Вот именно в таком случае - оно и сработает и обнаружит нарушение эксклюзивности.
Команда LDREX взводит некий триггер в "1". STREX атомарно сбрасывает его и, если в в момент своего выполнения триггер стоял - выполняет операцию, если не стоял - не выполняет. И возвращает соотв. значение.
Также любое прерывание сбрасывает этот триггер. А также команда CLREX тоже сбрасывает.
Вот и всё. Всё просто.