Как отловить глюк, приводящий к HardFault, Появляется и исчезает при добавлении/удалении строк кода Опции

[haker_fox]

Добрый день, господа!

Я понимаю, что проблема не имеет прямого отношения к FreeRTOS, но всё же.

Я использую версию 8.2.3 на LPC1768. Компилятор IAR 7.5.

Что наблюдается. Периодически прога стала вылетать в HardFault. Причём, если код немного перекомпилировать, буквально добавить/убавить строку, то всё работает прекрасно.

Я смотрел на адреса в обработчике HardFault, но не могу понять, как возникает ошибка, т.к. эти адреса указывают то на файлы самой оси, то на мой код. Может быть есть какая-то проблема именно с Cortex-M3 и именно с этой версией, о которой все знают, а я не знаю?

Да, включен монитор стека, он не переполняется, либо монитор не ловит ошибку.

В общем я в лёгком отчаянии, не знаю, как ловить глюк. Код довольно объёмный на текущий момент времени, поэтому по частям уже прогу не проверишь...

Спасибо за любой совет!

[aaarrr]

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

Помимо адреса у fault'а есть еще и причина, что с ней?

Касательно FreeRTOS, проверьте приоритеты прерываний, в которых используются системные вызовы.

[haker_fox]

Помимо адреса у fault'а есть еще и причина, что с ней?

Вот пример моего)

CODE

[HARD FAULT HANDLER]
R0 = 0x18400D4E
R1 = 0x2
R2 = 0x100046E0
R3 = 0x10000648
R12 = 0x21D8
LR [R14] = 0xA0BF  subroutine call return address
PC [R15] = 0xA0D4  program counter
PSR = 0x21000000
BFAR = 0x18400D56
CFSR = 0x8200
HFSR = 0x40000000
DFSR = 0x0
AFSR = 0x0

Касательно FreeRTOS, проверьте приоритеты прерываний, в которых используются системные вызовы.

В ней (фриртос) есть фича, которая не позволяет поставить неправильные приоритеты (выдаёт ассерт), или вы о другом?

CODE

void HardFault_Handler(void)
{
    volatile bool is_break = false;
    while(!is_break)
    {
    }
}

А вот этот трюк (насколько помню предложен Сергеем Борщ), не помогает найти место откуда вылетело?

Этот трюк вижу впервые.

Но вообще похоже на проблемы со стеком/хипом. Хип используется, если да, то проверяли?

Хип-менеджер используют от уважаемого zltigo, выложенный лет пять назад. Вроде в нём все баги выловили...

Лучше смотреть таймлайн и анализировать как с моментом вылета коррелируют события прерываний.
Я бы поставил на то, что проблема скрывается в прерываниях.

С этой техникой не знаком, можно подробнее (ссылочку, например?)
Кстати, под отладчиком оно не возникает (исключение).

[zltigo]

Вот пример моего)

У меня еще сохраняется и распечатывается кусочек из 8 значений стека, дабы можно было видеть, как дошли до жизни такой. То что у Вас творится это наверняка порушенный стек с возвратом неведомо куда .
Типа так:
Abort:[D] PC:0000BFD8 Op:E5315004 CPSR:00000092
LR:0000C564 SP:40001F88
SP[0]:00000000->00000000->00000000->0000C2E0->
SP[4]:00013413->00000000->E01FC0C4->0000BE58
R0:E59FF018 R1:259FF15C R2:E59FD1B8 R3:CB3FC1D0 R4:3967F46E R5:EFBFF1F0
R6:E0024000 R7:00000002 R8:4000006C R9:00000000 R10:00000001 R11:000007D7
R12:00002000

Может быть есть какая-то проблема именно с Cortex-M3 и именно с этой версией, о которой все знают, а я не знаю?

Относительно версий и проблем что-то может быть только в части порта. сравните, что там в 9 версии относительно Вашей поменяли, хотя думаю, что ничего.
Могу свой вариант порта на M3 выложить, то там ничего, насколько я помню, уникального нет.

[haker_fox]

Abort:[D] PC:0000BFD8 Op:E5315004 CPSR:00000092
LR:0000C564 SP:40001F88
SP[0]:00000000->00000000->00000000->0000C2E0->
SP[4]:00013413->00000000->E01FC0C4->0000BE58
R0:E59FF018 R1:259FF15C R2:E59FD1B8 R3:CB3FC1D0 R4:3967F46E R5:EFBFF1F0
R6:E0024000 R7:00000002 R8:4000006C R9:00000000 R10:00000001 R11:000007D7
R12:00002000

Давно в эту ветку не заглядывал, а оказывается здесь появились ответы Вам не сложно выложить свой обработчик hard_fault'a?