«Исключение ошибки использования» в ARM Cortex M

На Cortex-M (некоторые из них) текущий контекст будет храниться в используемом стеке до прерывания (при входе в прерывание), поэтому, если вы были в задаче, и она была прервана, часть текущего контекста будет сохранена в задаче. стек (через PSP). Само прерывание всегда выполняется на MSP. Если прерывание не возвращается к задаче, которую оно прервало, то прерванная задача будет иметь испорченный стек (поскольку она восстанавливает сохраненный контекст при выходе), а также попытается восстановить неправильный контекст для задачи, на которую было переключено.

При переключении контекста (которое происходит в прерывании) часть контекста снова автоматически сохраняется в стеке задач, но ОС также сохраняет остальную часть контекста в стеке задач. Когда он выполняет переключение и выходит из прерывания, ОС восстанавливает контекст, который она сохранила для задачи, а затем остальная часть контекста автоматически восстанавливается при выходе из прерывания. Это работает, поскольку гарантируется, что стек остается в правильном формате. Посмотрите на вход/выход прерывания в Универсальном руководстве пользователя Cortex-M4.

Не все процессоры так работают.

Этот ответ является общим, а не специфичным для FreeRTOS или Cortex-M - он применим к любой типичной RTOS на любой платформе:

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

Специальные версии функций ISR не вызывают планировщик немедленно; вместо этого они устанавливают флаг, указывающий, что планировщик должен запускаться при выходе из контекста прерывания.

Обычно ISR, выполняющий вызовы API RTOS, должен иметь пролог и эпилог; определенные вызовы входа/выхода прерывания или макросы. Этот пролог увеличивает счетчик, который уменьшается в эпилоге; если счетчик равен нулю и установлен флаг расписания, планировщик запустится. Счетчик предназначен для предотвращения запуска планировщика при выходе из вложенного прерывания. Это гарантирует, что планировщик запускается только один раз при выходе из ожидающего прерывания с самым низким приоритетом.

Возникнет ли «ошибка uasge» или почему это произойдет, зависит от конкретных деталей реализации FreeRTOS и в значительной степени академического характера. RTOS также может перехватывать использование безопасного вызова, не связанного с ISR, в ISR и запускать более конкретный обработчик ошибок, если он не удосужится сделать это, то результирующее поведение может вызвать ошибку использования; это кажется несколько грубым механизмом, на который можно положиться; Ошибка использования — это очень широкая ловушка, которая может произойти по ряду причин:

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

Некоторые RTOS не имеют специальных функций ISR, вместо этого вызовы API, которые вызывают планирование, обнаруживают внутренний контекст ISR и ведут себя по-разному в этом контексте — это проще и безопаснее для программиста, но несет небольшие накладные расходы для проверки контекста при каждом таком вызове. . API, который обеспечивает внутреннюю безопасность ISR, также означает, что вызов функций, которые сами могут выполнять вызовы OS API, проще, поскольку сами эти функции не обязательно должны быть специфичными для ISR.