К решению какой задачи? Про сферического коня в вакууме в которой специально создаются некие условия, отметается другая постановка задачи и системные решения и начинается решаться "задача"?

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

DMA, FIFO а так-же, прочие "ценные ресурсы" контролера не должны использоваться, потому, что потому ....

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



Не открытие, но за напоминание, безусловно спасибо.

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

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

А в чем, собственно, проблема? Ставьте WFI после обработки данных (см. код в первом сообщении), а не после приема. Разве не логично?

Проблема понятна, можно даже не брать UART и прочее, гораздо абстрактнее

WFI засыпает до прерывания и если делать

_irq_disable();
.... //какие то проверки возможности уснуть
_irq_enable();
__WFI();

то есть шанс что прерывание произойдет между
_irq_enable();
//вот прямо вот здесь
__WFI();

соответственно оно будет обработано до __WFI, и не будет причиной пробуждения, то есть схема будет спать до следующего.

Поэтому правильно этот кусок кода писать в таком виде

_irq_disable();
.... //какие то проверки возможности уснуть
__WFI();
_irq_enable();

это просто надо запомнить, также как, что прерывания надо сбрасывать через присвоение (=), а не через &=, |=

Прошу пощения, как (чем) при запрещённых прерываниях ядро будет выведено из (цитирую ARM DDI 0403E.
"suspend execution and enter a low-power state. It can remain in that
state until the processor detects one of the following WFI wakeup events:
• A reset.
• An asynchronous exception at a priority that, if PRIMASK was set to 0, would preempt any currently active
exceptions.
Note
The processor ignores the value of PRIMASK in determining whether an asynchronous exception is a WFI
wakeup event.
• If debug is enabled, a debug event.
• An IMPLEMENTATION DEFINED WFI wakeup event."? (конец цитаты)

Какое событие из списка позволит исполнить _irq_enable()?

Т.е. уснуть и не проснуться?

О чем собственно и есть эта тема.

Как я понял __WFI(); - анализирует регистр битиков в векторе NVIC
в то время как
_irq_disable();
_irq_enable();
работает со статусным регистром проца.
потому когда вы делаете
_irq_disable();
вы запрещаете переход проца в обработку, но все механизмы нужные WFI для просыпания оставляете работоспособными. Уверености что это не получилось случайно, и что именно так они и хотели у меня нет, может это баг обращенный в фичу, но тем не менее...

Можно применить еще такой вариант:

Всё, согласен.
Мир устоял.

Где такое написано?

См. Note в цитате из мануала выше.

А что в ней написано?
В тех примерах, что я посмотрел, везде разрешаются прерывания перед использованием WFI.

Действительно, что?


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

Что независимо от запрещенных прерываний (установленного бита в BASEPRI командой _disable_irq) может разбудить процессор:
• событие Debug
• некое IMPLEMENTATION DEFINED WFI.
Это говорит о том, что любое запрещенное прерывание может разбудить процессор?

Неправильно. Примечание относится к пункту 2. Хорошо... будем искать дальше...

Вспомнился старый анекдот: "…Не ебонит!!! Целлюлёид!!!…"
PRIMASK