[Johnny81 0]

STM32F427, gcc

Есть устройство, которое раз в несколько часов падает в hard fault. В разных местах - в обычном коде, в прерываниях. Удалось повторить под отладчиком - упало в  SysTick_IRQHandler (стандартный от freertos)

Мой обработчик HardFault выдает

CFSR=0x00010000, // UNDEFINSTR
HFSR=0x40000000, // FORCED
DFSR=0x00000001,
AFSR=0x00000000
PC=0x080D6626;
LR=0xFFFFFFFD;
PSR=0x6100000F;
r0=0x00000000;
r1=0xA5A5A5A5;
r2=0x10000000;
r3=0xE000ED04;
r12=0xA5A5A5A5;
AFSR=0x00000000

Надо понимать, что это прерывание исполняется постоянно и все ок. Но иногда стреляет HardFault

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

Что это может быть такое? Куда копать? Может какая-то аппаратная проблема?

[HardEgor 62]

Что со стеком, не переполняется?

[Сергей Борщ 119]

Могут быть неверно выставлены такты ожидания контроллера флеша. Правда, в этом случае падает чаще, но, возможно, у вас они на грани.

[AVI-crak 0]

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

Ну и само прерывание SysTick работает весьма странно для arm. Регистры r0, r1, r2, r3, r12, LR, PC, xPSR сохраняются автоматически при входе в прерывание. Нет смысла сохранять r3, lr. Как оно объявлено-то?

[jcxz 184]

43 минуты назад, AVI-crak сказал:

Уровни прерываний, их всего 15 штук - читайте внимательней документацию. SysTick должен иметь максимальный уровень 15, и на этом уровне больше не должно быть прерываний.

Почему?

 

Цитата

Ну и само прерывание SysTick работает весьма странно для arm. Регистры r0, r1, r2, r3, r12, LR, PC, xPSR сохраняются автоматически при входе в прерывание. Нет смысла сохранять r3, lr. Как оно объявлено-то?

Это обычное поведение для ARM-компилятора. Загляните в любой .lst-файл и поищите.

LR сохраняется потому что есть вложенные вызовы других функций (команды BL), а R3 - для выравнивания стека на 8.

[jcxz 184]

2 часа назад, Johnny81 сказал:

Что это может быть такое? Куда копать? Может какая-то аппаратная проблема?

С такими симптомами - значит проблема уже очень запущена, баг видимо плавающий. Найти будет трудно.

Я бы сделал монитор выполнения: запустил прерывание от таймера на максимально возможной частоте, такой, чтобы прерывание случалось не реже чем каждые десяток команд кода. В ISR его сделал сохранение регистров и верхушки стека в кольцевой журнал. А потом, по факту попадания в HF, проанализировал содержимое журнала: в каком месте находилось выполнение непосредственно перед HF, какое состояние регистров, стека и т.п. Если причина HF-ов единственная, то вполне возможно как раз перед HF выполнение будет проходить по проблемному коду. Но конечно не обязательно.

В таких случаях очень помогает ETB (обратная отладка). Но этого в МК STM32 вроде как нет, к сожалению.

[Integro 0]

Нужно больше инфы!
- Какая версия FreeRTOS?
- ASSERT включены? Полезны!
- Tiсkless включен? или может в коде есть прямой переход в Sleep(вызов WFI)? WFI обвернут в DSB и ISB?
- Контроль переполнения стека средствами FreeRTOS включен, 1 или 2?
- Что со значением MSP и PSP? Не выходят ли за границы? Вершины стеков выравнены по 8?
- FPU включен? используется?

Как это понимать:

3 hours ago, Johnny81 said:

на чуть другой плате

Какие компоненты(питание или периферия)? Возможна ли генерация дополнительных прерываний(или на оборот) на этих платах? Какие интерфейсы задействованы? Ревизия MCU та же?

 

3 hours ago, Johnny81 said:

При этом та же самая прошивка

Буквально та же самая, байт в байт?

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

[jcxz 184]

10 минут назад, Integro сказал:

WFI обвернут в DSB и ISB?

А это зачем?

[Integro 0]

34 minutes ago, jcxz said:

А это зачем?

Так вроде как известная тема, про DSB и WFI а здесь про интеррапты и ISB
FreeRTOS например, так с 8 версии делает

[jcxz 184]

31 минуту назад, Integro сказал:

Так вроде как известная тема, про DSB и WFI

Понятно. Сам так не делаю, так как у меня WFE только в одном месте - в отдельной Idle-задаче. Которая кроме выполнения в цикле WFE больше собственно ничего не делает. А переход в эту задачу - через переключатель контекста.

Такую Idle-задачу использую во всех проектах, в том числе и на STM32. Проблем нигде нет.

 

Цитата

а здесь про интеррапты и ISB

Тоже - не делаю так. Т.е. - не строю код так, чтобы была зависимость от задержек входа в ISR.

 

PS: Проблемы ТС думаю не из-за этого. Так как в первом случае - у него были бы проблемы с работой периферии, а не HF; а во втором - с входами в ISR, а не HF.

 

PPS: В исходном посте мне не понятна последняя строка: portCLEAR_INTERRUPT_MASK() - что это? и зачем?

А также: как задана и чему равна portSET_INTERRUPT_MASK_FROM_ISR() ?

Случайно не:

#ifndef portSET_INTERRUPT_MASK_FROM_ISR
  #define portSET_INTERRUPT_MASK_FROM_ISR() 0
#endif

[scifi 1]

В продолжение сказанного выше про настройки флеша, я бы ещё посмотрел в сторону цепей питания. Если на Vdda всё плохо, возможны любые чудеса.

[Johnny81 0]

4 hours ago, HardEgor said:

Что со стеком, не переполняется?

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

1 hour ago, Integro said:

Нужно больше инфы!
- Какая версия FreeRTOS?
- ASSERT включены? Полезны!
- Tiсkless включен? или может в коде есть прямой переход в Sleep(вызов WFI)? WFI обвернут в DSB и ISB?
- Контроль переполнения стека средствами FreeRTOS включен, 1 или 2?
- Что со значением MSP и PSP? Не выходят ли за границы? Вершины стеков выравнены по 8?
- FPU включен? используется?

- 7.4.0, старенькая, пока проблем не было
- да
- сон не испльзуется
- контроль стека включен, уровень 1. Стеки с двукратным запасом примерно
- выровнены, вроде как норм
- включен, используется

3 hours ago, Сергей Борщ said:

Могут быть неверно выставлены такты ожидания контроллера флеша. Правда, в этом случае падает чаще, но, возможно, у вас они на грани.

__attribute__(( naked )) unsigned long ulPortSetInterruptMask( void )
{
	__asm volatile														\
	(																	\
		"	mrs r0, basepri											\n" \
		"	mov r1, %0												\n"	\
		"	msr basepri, r1											\n" \
		"	bx lr													\n" \
		:: "i" ( configMAX_SYSCALL_INTERRUPT_PRIORITY ) : "r0", "r1"	\
	);

	/* This return will not be reached but is necessary to prevent compiler
	warnings. */
	return 0;
}

__attribute__(( naked )) void vPortClearInterruptMask( unsigned long ulNewMaskValue )
{
    __asm volatile                                                    \
    (                                                                \
        "    msr basepri, r0                                        \n"    \
        "    bx lr                                                \n" \
        :::"r0"                                                        \
    );

    /* Just to avoid compiler warnings. */
    ( void ) ulNewMaskValue;
}

3 hours ago, Сергей Борщ said:

Могут быть неверно выставлены такты ожидания контроллера флеша. Правда, в этом случае падает чаще, но, возможно, у вас они на грани.

Генератор 25МГц, рабочая частота 168 МГц, питание 3,3. FLASH_ACR latency стоит 5, глянул даташит - вроде как норм

[Johnny81 0]

А сам UNDEFINSTR ничего полезного не несет?

В книжке написано

1. Use of instructions not supported in Cortex-M3.
2. Bad/corrupted memory contents.
3. Loading of ARM object code during link stage. Checks compile steps.
4. Instruction align problem. For example, if GNU Tool chain is used, omitting
of .align after .ascii might cause next instruction to be unaligned (start in odd
memory address instead of halfword addresses).

 

С учетом того, что этот код обычно работает нормально, остается причина 2. Т.е. проц неверно читает FLASH?
 

[jcxz 184]

7 минут назад, Johnny81 сказал:

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

При переполнении стека может быть что угодно, в том числе и ваша ситуация. Программный контроль стека помогает не всегда.

[Johnny81 0]

5 minutes ago, jcxz said:

При переполнении стека может быть что угодно, в том числе и ваша ситуация. Программный контроль стека помогает не всегда.

спасибо, пробегусь по стекам процессов