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

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

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

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

спасибо.

А разве кому-то нужен энергозависимый журнал?

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


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

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


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

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


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


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

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

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

да ну?
Вот Вы видите что выход произошёл на:
MOVS R0, #1
ADDS R1, #2
LSLS R1, R1, #1
ITT MI
MOVSMI R2,#1
MOVSMI R3,#2
...
и ещё пару десятков подобных команд до этого. И где же глюк? Даже ни одного обращения к памяти нету.
А глюк оказывается был вообще в другой задаче, из которой управление только, что было передано сюда (например - переполнение её стека, запись в несуществующую/запрещённую память как раз в момент сохранения контекста, которая из-за наличия отложенной записи выдала Imprecise Bus Fault).
Или он вообще был в ISR, который только что завершился BX LR.
Или наоборот - это код в ISR, который только что прервал задачу, в которой и произошёл данный сбой.
И где точно - Вы не знаете так как неточная ошибка памяти она на то и неточная - что где-то за несколько команд или десяток команд ранее случилась до входа в fault.

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

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

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

Будем считать, что мне везло, и я всегда попадал именно в ту функцию, которая вызвала HF. (кэшей не было, точно)
А что вы найдете в этом случае через регистры, как писали выше?

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

Только не в случае Imprecise Bus Fault, разве не так?

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

Короче, при HF первым делом нужно проверять (в порядке важности):
отсутствие любых предупреждений при компиляции (иногда даже стоит ужесточить условия их формирования), должно быть "Warinigs: 0"
объем стека/стеков и кучи,
конкурентный доступ к переменным из кода и прерываний (особое внимание обратить на глобальные переменные, которые используются в прерываниях),
все указатели, а особенно те, которые используются с приведением типа,
доступ к не инициализированным локальным переменным,
если есть RTOS и используются приоритеты прерываний, то убедится, что нет вызовов сервисов оси из обработчиков, приоритет прерываний которых выше значения, заданного в настройках оси (FreeRTOS),
ну и может еще что, с ходу не вспомню ))

В смысле мне себя почитать?




Я обычно в таких случаях смотрю ассемблерный код - это намного продуктивнее.

А я под словом "продуктивный" понимаю такой код, который вообще исключает всякую необходимость рыться в "белье" компилятора

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

Честно говоря - не помню уже. Обработчик fault-ов написал несколько лет назад. И забыл про эту проблему и какие конкретно регистры надо читать - он их сам читает и показывает когда надо.

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