stm32f103 + FreeRTOS непонятный hard fault и ещё кое что

Делаю программу для управления двигателем. В основе stm32f103c8t6 на нём FriiRTOS 8 версии. Есть не периодическая задача обработки данных из CAN. Также есть 3 периодических: опрос датчика тока, обработка ПИД регулятора пересчёт текущей скорости или положения вала, т.к. в виде обратной связи используется или квадратурный энкодер или потенциометр. Тики энкодера обрабатываются в прерываниях по одной из линий.

Проблем две.

Первая - это иногда возникающий hard fault, причём судя по той статистике что у меня есть он возникает когда в качестве обратной связи энкодер. Больше сказать не могу, так как он возникает непредсказуемо.

Вторая более интересная. Кто пытался во фриртосе сделать return из таска наверняка знает чем это заканчивается. Вызовом обработчика этого безобразия, а именно функции static void prvTaskExitError( void ) из port.c. Так вот у меня эта функция вызывается просто так. Опять же из той статистики которая у меня есть абсолютно не понятно что является причиной вызова этой функции, т.к. ни в одном таске ретёрна нет. И программа улетает в неё совсем не предсказуемо.

Обе эти проблемы возникают непредсказуемо, программа может работать полтора часа и вылететь в одну из этих ошибок, а может через 5 минут работы

Вопрос больше каким образом обнаружить источник ошибки? До этого заметил, что при переполнении переменной типа ftoot мк улетал в hard fault, сейчас суммирования нет нигде и переполняться нечему. В программе использую очереди типа uint8_t, а потом полученный данные из очереди использую как индекс массива. Может быть тут что-то не так? Может ли это быть результат переполнение стека?
В общем буду признателен любой помощи.

0

Я тут малость накатал некоторые мысли про ХардФолт и как его дебажить

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

Про первую проблему - смотрите в сторону приоритетов прерываний. Что то мне подсказывает - что дело в них.

0

кроме приоритетов прерываний можно посмотреть какие FriiRTOS функции используются в контексте прерывания. А именно должны использоваться только *fromISR версии.

В программе использую очереди типа uint8_t, а потом полученный данные из очереди использую как индекс массива

Еще можно посмотреть может где-то происходит запись в массив, когда он еще не прочитался. И в итоге обрабатываются неверные данные. Нужно расставить проверки, проверить все возможности выхода за пределы массивов, проверять максимальные и минимальные значения индексов взятых из пакета и т.д.

причём судя по той статистике что у меня есть он возникает когда в качестве обратной связи энкодер.

я бы начал копать с прерываний обработки энкодера

0

Спасибо за ответы. Помогли покопаться в нужную сторону. Увеличил размера стека задач, изменил приоритеты прерываний. А так же переделал логику обработки сообщений из CAN. Раньше у меня по приходу сообщения создавалась задача обработки, которая удалялась после выполнения. В проекте на ф407 такая система работала без проблем, а вот тут почему то нет. В итоге поставил её циклично выполняться и сигнал о новом сообщении передаю через семафор. Теперь вроде всё работает нормально.

0

по поводу создания и удаления задач - какой heap был выбран? Там есть тонкости. Некоторые heap не предназначены для удаления задач, какие-то оставляют фрагментированные фрагменты, и новые задачи должны быть размером такие-же, как и удаленные. Возможно у вас просто кончалась куча, из-за того что задачи были с разным размером стека и после удаления оставались мелкие фрагментированные кусочки.

0