Программа стабильно оказывается в Busfault Handler
Значения регистров стабильно равны
SCB->CFSR = 0x00008200
SCB->BFAR = 0x1800F267
Попадание в Busfault Handler совпадает по времени с запуском или работой DMA + SDIO
ОС FreeRTOS

Вопросы :
1) Правильно ли я понимаю, что 0x1800F267 это адрес, по которому программа попыталась вернутся из функции или прерывания, и не смогла, т.к. этот адрес не существующий ?
2) Верно ли предположение, что загрузка неправильного адреса в PC происходит пре переключении контекста ОС ?
3) Что делать дальше ? В какую сторону думать ?


Заранее спасибо !

Стеки увеличить?

Нет, это адрес, попытка доступа к которому вызвала исключение. Адрес инструкции, при выполнении которой случился bus fault, можно получить из stack frame.

Мне не нравится число 0x1800F267. Наверное в выравнивании по 4 байта проблема.

Проверьте значение указателей и добейтесь чтобы они делились на 4.

Это же кортекс, там нет арм режима. Поэтому младший битик д.б. равен 1

Надо же! Век живи -- век учись.

Проблему удалось решить.
Нашёлся указатель, который вылетал и что-то портил в ОС
Впрочем, он нашёлся случайно.
Как систематизировать его поиск, имея исходные данные SCB->BFAR = 0x1800F267 , осталось неясным.

А так?

Надо где-нибудь большими буквами написать, что основным источником данных для разборок с fault'ами на Cortex-M является содержимое стека, а не регистров (хотя они, бесспорно, тоже нужны). Регулярно всплывает этот вопрос.

Это плата за использование операционной системы. Ошибку можно никогда не найти.

Операционка-то причём????

Притом что вылет, как правило, происходит в момент работы с семафорами/очередями. В том числе, в момент переключения контекста.
Приходится выяснять, какой объект поганится, какие переменные лежат до/после него, потом смотреть, кто с этими переменными работает. Либо ставить бряку на диапазон адресов.

И что? Проблема на 99.99% в пользовательском ПО. Если оно криво написано, то оно такое же кривое будет и без ОС. Наличие ОС не влияет на сложность поиска багов.