Коллеги, добрый день.
Подскажите что-нибудь !

После выхода из обработчика прерывания SDIO программа оказывается в BusFault_Handler. Глюк происходит изредка и нерегулярно.
В окне Callstuck картина каждый раз одинаковая, глюк где-то в коде ядра ОС
Если установку эвентов в прерывании заменить на глобальную переменную, а ожидание эвентов на проверку этой переменной в цикле while , то глюка не происходит.

Приоритет прерывания 12.

FreeRTOS настроена так :


Обработчик прерывания

Смотрите значения BFSR и BFAR.

CFSR = 0x00008200 (во всех случаях)
То есть, стоят биты
15 BFARVALID BFAR holds a valid fault address.
9 PRECISERR Precise data bus error . A data bus error has occurred, and the PC value stacked for the exception return points to
the instruction that caused the fault.

BFAR=0xE000ED00 или 0xC0008830
Что по этим адресам, показано на картинках.

Мне не приходит в голову, что со всем этим делать.

Ещё, заметил, что глюк происходит не в одном месте, а в двух: а)во время ожидания эвента из прерывания(чаще) , и б) во время ожидания другого эвента просто из задачи. Т.е. вроде как и с прерыванием не связано, а связано только с эвентом. Множество других эвентов работают без проблем.

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

Вот такой массив их эвентов и такое обращение к нему причиной проблемы быть не может ?
Я что-то засомневался, ведь EventGroupHandle_t это указатель.
Получается объявление аналогичное
char *x[2];

А где циферка-то? Чему равно SD_CARDS_COUNT?

Опечатка, в коде #define SD_CARDS_COUNT 2

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

муторно конечно же, но причину отроете обязательно в конце концов.

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

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

Другой вопрос:
Делаю xTimerResetFromISR , после этого программа попадает в функцию таймера, и в это время в окне Call Stack появляется prvTaskExitError . Откуда эта ошибка ? Она означает, что программа где-то вышла из бесконечного цикла внутри задачи, так ? Для чистоты эксперимента, никаких задачь нету. есть только функция таймера и прерывание (от кнопки).

Приоритеты прерываний настроены?

Вроде бы да :
#define configMAX_SYSCALL_INTERRUPT_PRIORITY 0xb0
Т.к. в STM32 для определения приоритета используются биты 7-4 , то это приоритет 0xB или 11.
Стало быть, те прерывания, где есть функции API , должны иметь приоритеты ниже, т.е. 15-11 включительно. У меня так и сделано.
Всё верно ?

Вроде так. А subpriority зарублены?

Не совсем понимаю вопроса. У меня у всех прерываний разные приоритеты. Вроде бы это означает, что о субприоритетах можно не думать.

Можно не думать, только если Вы не пользуетесь NVIC_Init() или установлен режим без субприоритетов - NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 ),
в противном случае приоритеты ОС (MAX_SYSCALL_INTERRUPT_PRIORITY) и прерываний, сконфигурированных вызовом NVIC_Init(),
окажутся в разных размерностях.

Картина проясняется.

Есть две задачи.
Есть два несвязанных друг с другом прерывания. Первое прерывание выдаёт симафор в первую задачу, второе эвенты во вторую.
И время от времени из-за какого-то наложения прерываний друг на друга возникает BusFault.
Бит 9 в CFSR говорит о том что : "PRECISERR Precise data bus error . A data bus error has occurred, and the PC value stacked for the exception return points to
the instruction that caused the fault" Т.е. речь как раз о проблеме при выходе из прерывания, из стека в PC загружается неправильное значение !!!!



В регистр SCB->AIRCR есть поле PRIGROUP , в котором задаётся, какие из 8и битов обозначают приоритет а какие субприоритет.
Раньше это поле было 0, хотя такого значения в документации нету, непонятно что это значит.
Сейчас пишу значение 3, т.е. 4 старших бита означают приоритет, субприоритетов нет.
Проверяю что записалось и что больше никогда не меняется.
Для конфигурации прерываний использую стандартные Кейловские NVIC_SetPriority и NVIC_EnableIRQ. Они пушут приоритет в старшие 4 бита, как и надо.
Вроде бы теперь настроил правильно, но глюк остался.
Вопрос: где в операционке настраивается то же самое ? Каким образом операционка понимает, в какие биты нужно писать её приоритеты ?

Совсем не так. Случилась ошибка доступа к данным (скажем, обращение по несуществующему адресу), сохраненное значение PC содержит адрес инструкции, вызвавшей исключение.


Проверьте значения непосредственно в регистрах NVIC. В ОС нигде не настраивается, просто задается число для записи в регистр.

А какие вообще прерывания использует ОС и зачем ? Помимо системного тика. Зачем ей прерывания приоритетом выше чем configMAX_SYSCALL_INTERRUPT_PRIORITY 0x60 (т.е. 6) , и почему это значение разрешается устанавливать самому ?

С приоритетом KERNEL_INTERRUPT_PRIORITY работают все прерывания ОС: SysTick, PendSV и SVCall.
Уровнем MAX_SYSCALL_INTERRUPT_PRIORITY задается максимальный приоритет, на котором может быть осуществлен системный вызов. Понятно, что в системе могут быть прерывания с более высоким приоритетом, которые не используют сервисы ОС. Для них и предусмотрено конфигурирование.

SysTick, PendSV в SCB_SHPR ОС устанавливает самые низкие, 0xF0 . Приоритет SVCall самый высокий 0 , и я не вижу места, где бы он устанавливался.

SVCall действительно не устанавливается, но он и используется однократно, так что все равно.

Поэкспериментировал ещё :

Оказывается, если заменить выдачу из прерывания эвента на симафор, то всё работает. Причём дело даже не в выдаче эвента из прерывания, а просто в том, что использование функции ожидания эвента каким-то неудачным образом накладывается на момент прерывания, и вот при этом происходит Bus Fault . Что-то не так именно с эвентами !

Сломается точно так же и с семафорами в конце концов. Смысл экспериментов в чем?

Ключи все у Вас в руках:
1. Имеем Precise data bus error
2. Есть адрес инструкции, его вызвавшей
3. Известны ошибочные адреса (BFAR), по которым было обращение
Порой достаточно даже одного п.3: по характеру данных можно установить виновника.

Попробуйте своим прерываниям выставить минимальный приоритет (0xF0), посмотрите, будут ли воспроизводится проблемы.

Проблема решилась.
После перехода с версии FreeRTOS 8.0.0 на 8.2.0 её не стало.
Выходит , что 8.0.0 была с глюком.
В общей сложности потратил на ковыряние недели 2 чистого времени. Причём начал тратить ещё тогда, когда версия 8.2.0 ещё и не вышла.

Из первого, увы, никак не следует второе. В history ничего похожего нет.

у меня аналогичное случалось при банальном переполнении стека, по умолчанию в кейле, например не достаточно для такого примера