Hard Fault Exception на кортексе м3, как узнать откуда прилезло Опции

[klen]

Здравствуйте.
работает программа на stm32f107 uIP+DHCP+HTTPD+TELNETD.

все просто замечательно работает, но не долго - минуту, через примерно одинаковый интервал времени - systick показывает очень близкие значения, все вываливается в HardFaultException с вероятностью 1. видимо гдето чето кончаетсо, буфер например. пытаюсь понять.

как высчитать в обработчике адрес с которого все это прилитело?

нагугленная конструкция
asm volatile ("MRS R0,PSP") ;
asm volatile ("LDR R1,[R0,#24] \n");
выдает чето мне непонятное.

спасибо.

[Obam]

А что, на брейкпойнте в точке входа в HF и под JTAGом, нельзя посмотреть содержимое регистров без портянки из printf-ов?
Просто интересуюсь…

[juvf]

А что, на брейкпойнте в точке входа в HF и под JTAGом, нельзя посмотреть содержимое регистров без портянки из printf-ов?
Просто интересуюсь…

По мойму нельзя.

[Шаманъ]

По мойму нельзя.

Можно. Более того есть смысл оформить обработчик так:

Код

void Default_Handler(void)
{
volatile int i = 1;
  while (i)
  {
  }
}

Тогда можно переменную i в отладчике поменять на 0 и пройтись до выхода из HardFault, выйдет как раз в место его возникновения, бывает очень удобно. Можно конечно адрес из стека вытащить, но так проще, удобней, нагляднее.

[jcxz]

Тогда можно переменную i в отладчике поменять на 0 и пройтись до выхода из HardFault, выйдет как раз в место его возникновения, бывает очень удобно. Можно конечно адрес из стека вытащить, но так проще, удобней, нагляднее.

У Cortex есть неточные ошибки с памятью (Imprecise Bus Fault). Так Вы их место не найдёте. А через регистры - найдёте.
Да и очень неудобно каждый раз вспоминать где какой стек, лучше иметь готовый код.
Не зря же даже в винде подобный обработчик сделали с регистрами и стеком (синий экран). Вот у меня как раз подобный для Cortex есть

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

Это конечно всё хорошо и правильно. Но на практике почему-то случаются такие ошибки (в том числе и HF), которые проявляются почему-то только у заказчика
Вот тут-то фиксация в журнал спасает (а особенно - в энергонезависимый).

[ViKo]

У Cortex есть неточные ошибки с памятью (Imprecise Bus Fault). Так Вы их место не найдёте. А через регистры - найдёте.
Да и очень неудобно каждый раз вспоминать где какой стек, лучше иметь готовый код.

А не надо думать про стек. При шаге - возврате из обработчика - попадете туда, откуда упали.

Но на практике почему-то случаются такие ошибки (в том числе и HF), которые проявляются почему-то только у заказчика

Летом было. На скорую руку поправил одну функцию, типа, улучшил, по требованию. Проверил - работает, да и забыл про нее. Отправили 10 приборов в Нижний Новгород. Там они все "зависли намертво". Вернулись назад. Причину нашел быстро. Если бы там были лучшие умельцы, могли бы обновить программу сами. Но таковых не оказалось. Я уже заподозрил в попытке взлома...

[jcxz]

А не надо думать про стек. При шаге - возврате из обработчика - попадете туда, откуда упали.

Не обязательно. Прочитайте про неточные ошибки с памятью. Fault может произойти через несколько команд после места ошибки. Когда уже может выполняться другая функция или даже другая задача ОС или ISR. Возвращаетесь так по LR, а в том месте даже команд обращения к памяти вообще нет.

Вернулись назад. Причину нашел быстро. Если бы там были лучшие умельцы, могли бы обновить программу сами. Но таковых не оказалось. Я уже заподозрил в попытке взлома...

Надо делать удалённое обновление.

ViKo уже ответил, все произойдет само - вернетесь туда откуда выпали, вне зависимости от используемого стека.

И Вам тоже - читать мануал на ядро Cortex-M. Плюс - набраться опыта в отладке и ловле fault-ов.
Или тут все только с Cortex-M0 работают где нет кешей и буферов отложенной записи и т.п.? Ну так и это ненадолго.

[Шаманъ]

Не обязательно. Прочитайте про неточные ошибки с памятью. Fault может произойти через несколько команд после места ошибки. Когда уже может выполняться другая функция или даже другая задача ОС или ISR. Возвращаетесь так по LR, а в том месте даже команд обращения к памяти вообще нет.
И Вам тоже - читать мануал на ядро Cortex-M. Плюс - набраться опыта в отладке и ловле fault-ов.
Или тут все только с Cortex-M0 работают где нет кешей и буферов отложенной записи и т.п.? Ну так и это ненадолго.

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

Я на наличие универсального решения не претендовал. 99% разных fault отлавливаются приведенным выше алгоритмом. Если fault произошел не в той команде куда возвратились смотрим, что было до нее. Если совсем туго, то смотрим в регистр BFSR, оттуда можно почерпнуть полезной инфы в том числе произошла ли ошибка по адресу возврата или нет. Ну и если так ничего и не понятно через регистр ACTLR можно поотключать разные улучшатели и сделать из М7 почти что М0

Но, по моему опыту (М3/М7) обычно все отлавливается после возврата простым анализом 5..10 комманд до точки возврата.

[jcxz]

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

Читайте выше. Из соответствующих регистров можно прочитать реальный адрес где произошёл fault.