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

[dimka76]

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

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

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

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

[Forger]

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

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

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

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

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

[dimka76]

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

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

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

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

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

[Forger]

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

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

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

С "точки зрения архитектуры" в обработчике прерывания нужно сделать все, чтобы сделать девайс безопасным. Как можно быстрее!
Как именно это будет сделано - вопрос второстепенный.
Самое простое - тупо вызвать принудительный сброс всего проца.

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

[scifi]

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

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

Предлагаю другой план. Устанавливаем некий флаг "перевести ноги и зависнуть", вызываем программный сброс. Программа при старте проверяет условие "сброс == программный && флаг == установлен". Ну и при выполнении условия делает что надо. Так проще.

[Forger]

Предлагаю другой план. Устанавливаем некий флаг "перевести ноги и зависнуть", вызываем программный сброс.

Увы, на некоторых процах программный сброс != аппаратному сбросу.

[scifi]

Увы, на некоторых процах программный сброс != аппаратному сбросу.

Это уж пусть ТС разбирается. Во всяком случае, на STM32 команда программного сброса физически дёргает ногу RST. И даже не сбросится, если ногу подтянуть так, что дёргание не осилит.

[Forger]

Это уж пусть ТС разбирается.

Да вся эта тема - по сути баян, но раз уж подняли муть со дна, то не грех и чуток погундеть, благо пятница

Во всяком случае, на STM32 команда программного сброса физически дёргает ногу RST.

Не совсем - содержимое ОЗУ все же сохраняется. Но это даже к лучшему ))

[aaarrr]

Не совсем - содержимое ОЗУ все же сохраняется. Но это даже к лучшему ))

А что, POR сбрасывает ОЗУ?

[Forger]

А что, POR сбрасывает ОЗУ?

У STM32 - не сбрасывает, просто в этом случае там будет "каша".

[aaarrr]

У STM32 - не сбрасывает, просто в этом случае там "каша".

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

[scifi]

Не совсем - содержимое ОЗУ все же сохраняется. Но это даже к лучшему ))

Ага, лишь бы возразить. У ОЗУ не бывает сигнала сброса. Ну или это какое-то чудесатое ОЗУ.

[Forger]

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

Честно говоря тоже, но в свете новых событий обнуление ОЗУ при сбросе становится уже необходимостью

У ОЗУ не бывает сигнала сброса.

ОЗУ бывают разные, в том числе внешние

[scifi]

Честно говоря тоже, но в свете новых событий обнуление ОЗУ при сбросе становится уже необходимостью

Сенсация. Обнаружен способ стащить деньги из кошелька. Для этого нужен физический доступ к кошельку.

[Forger]

Сенсация. Обнаружен способ стащить деньги из кошелька. Для этого нужен физический доступ к кошельку.

Ага, лишь бы возразить.