STM32 Обработка hard fault exception, Как правильно с ним работать Опции

[Serj78]

Читаю документацию на ARM ( DDI0337e - Cortex™-M3 Revision: r1p1 Technical Reference Manual)

Хочется более полного понимания, от тех кто работал с системой исключений.

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

Из структуры стартап-файла (использую Keil 4.12) видно, что по каждому исключению может быть вызвано прерывание.

Очень вероятно, что назначением прерываний ведает Configurable Fault handler, упомянутый в вышеуказанном документе (DDI0337e).

Но как его включить (где описана структура управляющего регистра) ?

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

[sonycman]

У меня была как то проблема с таким вылетом - в исходниках FatFs от Чена есть такая функция - mem_cpy().
Весьма вредная, оказывается, так как при установленном флаге WORD_ACCESS она будет производить копирование 32-ух битными словами, а не байтами, безо всякого внимания к выравниванию.
Естественно, это быстро приводит к исключению.

Дело в том, что большая часть команд Cortex-M3 допускает работу с невыровненными по границе слова данными.
Но только не LDM и несколько других.

А именно они генерируются при компиляции Ченовской mem_cpy с флагом WORD_ACCESS.

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

[AHTOXA]

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

Я видел кучу самодельных реализаций memcpy(). Раз люди пишут, значит есть причины. Думаю, что основных претензий к библиотечной memcpy() две: она очень большая, и она медленная на маленьких кусках данных. Оба недостатка - следствие огромной кучи начальных проверок в стремлении копировать максимальными блоками. Не всегда это всё нужно. Например, я копирую блоки максимум 20 байт. В этом случае тупое побайтовое(!) копирование может быть быстрее memcpy(). Или наоборот, блоки большие, но я, как программист, гарантирую, что они будут выровнены. Зачем мне тогда начальные проверки memcpy()?
(А теперь представьте, что всё, что делает memcpy(), делает сам компилятор, принудительно?! )

[sonycman]

Я видел кучу самодельных реализаций memcpy(). Раз люди пишут, значит есть причины. Думаю, что основных претензий к библиотечной memcpy() две: она очень большая, и она медленная на маленьких кусках данных.

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

А насчёт "огромной" преогромной кучи проверок не соглашусь. Несколько битовых проверок с регистрами много времени не займут.
В отличии от примитивного побайтового цикла с обращением к памяти.