В текущем проекте сделал сохранение последнего исключения во внешнюю flash память для дальнейшего анализа (сохранение последней причины перезагрузки системы). Осталось это все дело протестировать. То есть написать тестовый код так, чтобы гарантированно вызвать исключения: NMI, HardFault, MemManage, BusFault, UsageFault.
Нашел как вызвать HardFault на просторах этого форума (попытка чтения по невыровненному адресу).



Как лучше/правильнее протестировать все остальные исключения?

Можно так конечно:

Но лучше создать условия при который вызываются исключения.
MemManage можно вызвать при нарушении защиты памяти - настройте MPU и прочитайте/запишите куда не положено.
UsageFault - возникает при делении на 0 (один из вариантов).
BusFault - ?? Непонятно как вызвать...
NMI:

Классика жанра - деление на ноль. Книги и интернет завалены примерами. У меня так

С HardFault вопросов как раз нету. Как, к примеру, BusFault вызвать (кроме, конечно BusFault() )? В каких книгах и интернетах это посмотреть?

А у Вас действительно эти обработчики заведены, настроены и разрешены?
Вам будет какая-то выгода, если вместо одного HardFault будут вызаваться все эти обработчики?
В конце концов есть регистры xFSR.
Естественно, что для "не-fault-овых" исключений (SysTick, NMI{CSS}, SVC) должен быть свой обработчик,
но во флеш при этом сохранять ничего не требуется.

Выгод то особых и нету (пока). Для анализа "что же произошло" на этапе тестирования достаточно HardFault.

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

Сообщение отредактировал mantech - Feb 26 2014, 08:11

Это все для того чтобы понять что же произошло у конечного пользователя, если что-то пойдет не так. Ведь обычно feedback приходит в виде "А я включил а оно не работает.... Оно то работает то не работает... итд".

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

+1
Исключительная ситуация возникает крайне редко. Чаще всего на этапе разработки софта.
В жизни (у разработанного изделия) ниразу не видел HardFault.


Это большое везенье если попали в HardFault.
Чаще всего программа работает как она написана, просто не все варианты разработчик учел.
С FreeRTOS чтобы попасть в HardFault или получить "странное" поведение системы достаточно запутаться с приоритетами прерываний
(на форуме обсуждалось неоднократно).
Был случай, когда у меня переполнялся софтовый таймер раз в 24 дня. Пока понял что к чему прошло пол года.
Изделие эксплуатировалось на столбе на автодороге (остановочное табло). После перезагрузки исправно работало
ровно 24 дня столько-то часов столько-то минут. Если бы сделал автоматическую перезагрузку, то в жизни бы не узнал
об ошибке).
Сейчас делаю watchdog, но по-умолчанию отключаю, чтоб проблему было явно видно.
Насчет обратной связи полностью с Вами согласен))

У меня так. А какое исключение вызывается, не помню. :-)

Ой, это то же самое, что в первом сообщении!

чукча не читатель, чукча писатель (из анекдота)

там как бы название функции само за себя говорит

"HardFault_generate"