Cortex-Mx, исключительные ситуации Опции

[dimka76]

Здравствуйте.

Возник такой вопрос.

Можно ли из обработчиков исключительных ситуаций вызывать функции ?
Не возникнет ли проблем со стеком ?

И еще.
Насколько я понимаю, обработчики исключительных ситуаций не могут прерваться прерываниями
от периферии ?

[Forger]

Можно ли из обработчиков исключительных ситуаций вызывать функции ?
Не возникнет ли проблем со стеком ?

В целом, такое прерывание не сильно то и отличается от всех других прерываний, поэтому вызов функций в них не запрещен, ведь для ядра нет понятия функция или т.п., но есть НО:
Если такое исключение возникло именно из-за проблем со стеком, то логично предположить, что сразу пользоваться стеком не стоит (точнее, таким указателем стека).
Также нужно учесть, что для прерываний обычно используют другой стек (точнее, указатель стека), особенно если применяется RTOS.
Более подробную информацию лучше см. в документации на выбранное ядро.

Насколько я понимаю, обработчики исключительных ситуаций не могут прерваться прерываниями
от периферии ?

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

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

[dimka76]

но есть НО:
Если такое исключение возникло именно из-за проблем со стеком, то логично предположить, что сразу пользоваться стеком не стоит (точнее, таким указателем стека).

Вот этот вариант и навел на вопрос. Спасибо, что подтвердили мои опасения.
У меня план такой. При попадании в исключительную ситуацию перевести некоторые ноги МК в определенное состояние.
И после этого зависнуть в этом прерывании навсегда.
А вот для управления нужными ногами у меня есть свои функции. Можно конечно прямо в прерывании
через регистры переключить ноги. Но мне кажется, что с точки зрения архитектуры программы это не правильно.

Думаю перед вызовом функции заново проинициализировать указатель стека значением из нулевого адреса.

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

RTOS не используется и режим работы не меняется. Поэтому указатель один, если я не ошибаюсь конечно )))

[jcxz]

У меня план такой. При попадании в исключительную ситуацию перевести некоторые ноги МК в определенное состояние.
И после этого зависнуть в этом прерывании навсегда.
А вот для управления нужными ногами у меня есть свои функции.

Выполняете CPSID I, CPSID F и после этого спокойно вызываете свои функции и зависаете. Только эти "свои функции" должны быть реентерабельны.

Честно говоря, не знаю семейств, где бы сброс обнулял содержимое ОЗУ. Хотя вполне допускаю, что и такое встречается.

Не обнуляется, но затирается часть - у многих.

Тема не как реализовывать обработчик исключений, а насколько безопасно просто так из него вызывать функции ))))

Сам вызов безопасен. А почему он должен быть не безопасен?
Только функция обязательно должна быть реентерабельной. Так как исключение может произойти в любой точке программы.

По-моему проще в обработчике исключения

Код

__set_MSP(TOP_RAM_ADDR);

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

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

Это на каком-же из МК (соответствующих заголовку темы) такое делается?

Вот есть мысля: при исключении писать в определенную область ОЗУ отладочную информацию, делать программный сброс (в STM32 типа NVIC Reset), а в коде при старте каждый раз проверять содержимое этой области.
Отличить полезную инфу от мусора в ОЗУ можно с помощью примитивных "маркеров" или элементарной контрольной суммы. Разумеется, эти данные нужно объявлять с соотв. квалификаторами или в соотв. не стираемой при старте секции.

Лучше использовать соответствующий периферийный регистр, где флажками указан тип сброса (POR, внешняя нога, WDT, программный, ...) и не возиться с флагами в ОЗУ, которые нужно ещё и правильно расположить.

[Forger]

Лучше использовать соответствующий периферийный регистр, где флажками указан тип сброса (POR, внешняя нога, WDT, программный, ...) и не возиться с флагами в ОЗУ, которые нужно ещё и правильно расположить.

Аппаратные флажки-то - это само собой.
Но имелось ввиду проверять валидность (актуальность) самих данных, дабы не спутать их с мусором в ОЗУ и не записать это мусор в журнал.