да ну?
Вот Вы видите что выход произошёл на:
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ы, то смысл заглянуть в ассемблер есть. А порыться в том, что наделал компилятор я лично люблю, бывает очень полезно и познавательно.

Честно, мне было бы вломы рыться в том, что там наделал компилятор на мою кривую конструкцию.
По мне быстрее и проще переписать саму кривую конструкцию, на которой вылезает fault, иначе этот fault вылезет в другом месте ....
Но если бесконечный поиск fault-ов и ковыряние в ассемблере - это некое хобби, то это меняет дело

У меня конструкции обычно достаточно прямые, чтобы код (в смысле сгенерированный компилятором) легко читался.


Не надо передергивать. За последние пол года могу вспомнить только два случая, оба решились в течении пары минут.

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

зы. Что-то тема пошла не в то русло ...

Та не, я ничего такого не имел ввиду. Извиняюсь, если кого-то обидел. В конце концов все мы когда-то знали и умели мало

Согласен, очень трудно делиться опытом так, чтобы это не звучало менторским тоном ... у меня ни разу не получалось )))