FreeRTOS ARM cortex hardfault escalation from systick

Question

В специальном состоянии я испытываю исключение из hardfault. ICSR указывает, что это эскалация из systick (ожидающее исключение = 15).

• Любые идеи, как это произойдет?

Я предполагаю, что это какой-то мертвый замок.

• Любые рекомендации по отслеживанию этого (без Atmel Studio)?

Я пользуюсь FreeRTOS 7.5.2.

UPDATE:

Я добавил еще несколько регистр ошибки в выходной дамп. Так что это действительно ошибка шины с SysTick прерывания в ожидании:

EXCEPTION HANDLER 
- ICSR active exception: 3 
- ICSR pending exception: 15 
- ICSR pending interrupt: 0 
- Hardfault status: 0x40000000 
    - Memory fault status: 0x00 
    - Bus fault status: 0x04 
    - Usage fault status: 0x0000 

Я был в состоянии отследить исключение вызова Freertos:

vTaskDelay(10/portTICK_RATE_MS); 

Приложение имеет 2 задачи:

1. Задача с приоритетом 2 (параметр xTaskCreate)
2. Задача с приоритетом 1

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

Answer 1

Я думаю, вы неправильно поняли ICSR. Это не означает, что исключение выросло из SYSTICK и не имеет ничего общего с жесткой ошибкой.

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

Затем вы можете отлаживать дальше отсюда. Если это тип ошибки шины (опять же вполне вероятно), вам нужно посмотреть бит BFARVALID в CFSR. Если это установлено, вам повезло, так как регистр BFAR будет содержать адрес ошибки. Если это не задано, все становится немного сложнее! Не имеет значения, тогда CFSR на самом деле является несколькими регистрами в одном, поэтому для правильного декодирования требуется некоторая часть бит, а некоторые из них являются ошибками памяти и т. Д.

Answer 2

Я не уверен, почему вы думаете, что [программное обеспечение ?] deadlock вызовет аппаратное сбоя, но некоторую информацию об отладке жестких неисправностей можно найти здесь: http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html

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