FreeRTOS - повреждение стека на STM32F4

Question

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

Я просмотрел FreeRTOS stack corruption on STM32F4 with gcc, но не получил помощи.

Приложение запускает две задачи и полагается на одно прерывание CAN. Рабочий процесс выглядит следующим образом:

1. две задачи, network_task и app_task создается вместе с двумя очередями, raw_msg_queue и app_msg_queue. Прерывание CAN также настроено.
2. Network_task имеет наивысший приоритет и начинает ждать raw_msg_queue неограниченно.
3. App_task следующий и начинает ждать app_msg_queue.
4. Прерывание CAN затем запускается из-за внешнего события, добавляя сообщение CAN к raw_msg_queue.
5. Network_task просыпается, обрабатывает сообщение, добавляет обработанное сообщение в app_msg_queue и затем продолжает ждать raw_msg_queue.
6. App_task просыпается, и я получаю жесткую ошибку.

Дело в том, что я завернул вызовы, которые app_task делает для xQueueReceive в два этапа из-за удобства и переносимости конечного пользователя. Целая функциональная цепочка app_task заключается в том, что она вызывает network_receive (..) -> os_queue_receive (..) -> xQueueReceive (..). Это работает хорошо, но когда он возвращается из xQueueReceive (..), ему удается вернуться к os_queue_receive (..), прежде чем он вернется в случайную ячейку памяти, и я получаю ошибку.

Размеры стека должны быть адекватными и установлены на 2048 для обоих, все крупные структуры данных передаются как указатели.

Я запускаю свой код на двух STM32F407. FreeRTOS находится в версии 7.4.2, самой последней на момент написания.

Я действительно надеюсь, что кто-то может помочь мне здесь!

Answer 1

Во-первых, вы можете посмотреть here и попытаться получить больше информации о жесткой ошибке. Вы также можете проверить настройку приоритета прерывания, поскольку сложный механизм приоритета прерываний ARM Cortex-M вызывает некоторые проблемы в FreeRTOS. См. here.

Answer 2

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

void vApplicationStackOverflowHook(xTaskHandle xTask, signed char *pcTaskName)

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

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