Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: STM32F417 вылетает в Hard Fault
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Quasar
Приветствую.

Есть самодельная плата на STM32F417 c Ethernet, LwIP и FreeRTOS. Она периодически улетает в Hard Fault, дамп привожу ниже. Улетает она с причиной NOCP.
Цитата
No coprocessor Usage Fault. The processor does not support coprocessor instructions: 0 = no Usage Fault caused by attempting to access a coprocessor
1 = the processor has attempted to access a coprocessor that does not exist.


Сначала думал FPU, но он включен, и вроде как исправно работает, на камне крутятся два фильтра, использующие FPU. Также, судя по дампу, вылет случается не на операции с плавающей точкой, а на операции UXTAH (см. приложенные картинки).

Есть подозрения, что проблема аппаратная, так как, на втором экземпляре слёт случается сильно реже, но все равно случается. Но мне не ясно, почему именно на это инструкции вылетает исключение? Может кто посоветует направление, где искать?

Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
vlad_new
Сталкивался с подобным. Помогло отключение, щас точно не помню, какого то буфера в камне. Вроде бы префеч ( ну или как его там ).
kolobok0
Цитата(Quasar @ Jul 7 2014, 18:42) *
Есть самодельная плата на STM32F417 c Ethernet, LwIP и FreeRTOS. Она периодически улетает в Hard Fault...


приблизительно такой-же фарш. Пока "проблемы по железу" всегда упирались в софт. Т.е. обычно из-за
невнятной(читай раскиданной по многим источникам) документации (последнее из этой оперы было - оконный вачдог + его IRQ.
но как всегда - софт наше всё). Но в интернете практически все ответы можно нарыть.

В Вашей связке, я бы пошёл в сокращении софтовой прослойки. Т.е. эмулировал бы обращение к "подозрительному железу"
без "лишнего софта". На мой взгляд - слабые софтовые звенья lwip & freertos. Там есть(скажеи так - встречаются) явные ляпы.
Сведите тестовый пример до "одного экрана" всех исходников. И будет Вам счастье. Ну или по дороге опознаете проблему.

кстати судя по дампам - у вас регистры левые... скорее всего уже загажены отладчиком или чем Вы там ловите. Правильно - опознание
через регистр LR. А вот он мне не нравится. Для пояснения приведу кусочек универсального обработчика на эту тему..

Код
    if (((lr & 0x0F) == 1) || ((lr & 0x0F) == 9))
    {
        CommonProcessingException(&sSave, msp);
    }
    else if ((lr & 0x0F) == 0x0D)
    {
        CommonProcessingException(&sSave, psp);
    }


У Вас явно не эти три случая. Согласны?
Quasar
Цитата(kolobok0 @ Jul 8 2014, 09:45) *
приблизительно такой-же фарш. Пока "проблемы по железу" всегда упирались в софт. Т.е. обычно из-за
невнятной(читай раскиданной по многим источникам) документации (последнее из этой оперы было - оконный вачдог + его IRQ.
но как всегда - софт наше всё). Но в интернете практически все ответы можно нарыть.

В Вашей связке, я бы пошёл в сокращении софтовой прослойки. Т.е. эмулировал бы обращение к "подозрительному железу"
без "лишнего софта". На мой взгляд - слабые софтовые звенья lwip & freertos. Там есть(скажеи так - встречаются) явные ляпы.
Сведите тестовый пример до "одного экрана" всех исходников. И будет Вам счастье. Ну или по дороге опознаете проблему.

кстати судя по дампам - у вас регистры левые... скорее всего уже загажены отладчиком или чем Вы там ловите. Правильно - опознание
через регистр LR. А вот он мне не нравится. Для пояснения приведу кусочек универсального обработчика на эту тему..

Код
    if (((lr & 0x0F) == 1) || ((lr & 0x0F) == 9))
    {
        CommonProcessingException(&sSave, msp);
    }
    else if ((lr & 0x0F) == 0x0D)
    {
        CommonProcessingException(&sSave, psp);
    }


У Вас явно не эти три случая. Согласны?


По поводу софта, если сократить прослойку вылетать перестает, НО перестает вылетать, даже если добавить какой-либо новый код к старой прослойке (FreeRTOS и LwIP), вроде как забываешь о проблеме, потом добавляешь еще код, опять начинается. То есть, образ софта немного меняется и ход исполнения соответственно тоже, вылеты исчезают. Почему я и подозреваю, что железо.
Тот дамп что скинул, он без отладчика, просто, в UART скинут. Код вот такой:

Код
HardFault_Handler\
                PROC
                EXPORT  HardFault_Handler          [WEAK]
                TST LR, #4
                ITE EQ
                MRSEQ R0, MSP
                MRSNE R0, PSP
                B hard_fault_handler_c
                ENDP


Код
void hard_fault_handler_c (unsigned int * hardfault_args)
{
  __IO unsigned int stack_ptr;
  __IO unsigned int stacked_r0;
  __IO unsigned int stacked_r1;
  __IO unsigned int stacked_r2;
  __IO unsigned int stacked_r3;
  __IO unsigned int stacked_r12;
  __IO unsigned int stacked_lr;
  __IO unsigned int stacked_pc;
  __IO unsigned int stacked_psr;

  stack_ptr = ((unsigned long) hardfault_args);
  stacked_r0 = ((unsigned long) hardfault_args[0]);
  stacked_r1 = ((unsigned long) hardfault_args[1]);
  stacked_r2 = ((unsigned long) hardfault_args[2]);
  stacked_r3 = ((unsigned long) hardfault_args[3]);

  stacked_r12 = ((unsigned long) hardfault_args[4]);
  stacked_lr = ((unsigned long) hardfault_args[5]);
  stacked_pc = ((unsigned long) hardfault_args[6]);
  stacked_psr = ((unsigned long) hardfault_args[7]);

  printf ("\n\n[Hard fault handler - all numbers in hex]\n");
  printf ("stack_ptr = %x\n", stack_ptr);
  printf ("R0 = %x\n", stacked_r0);
  printf ("R1 = %x\n", stacked_r1);
  printf ("R2 = %x\n", stacked_r2);
  printf ("R3 = %x\n", stacked_r3);
  printf ("R12 = %x\n", stacked_r12);
  printf ("LR [R14] = %x  subroutine call return address\n", stacked_lr);
  printf ("PC [R15] = %x  program counter\n", stacked_pc);
  printf ("PSR = %x\n", stacked_psr);
  printf ("BFAR = 0x%x\n", (uint32_t)(*((volatile unsigned long *)(0xE000ED38))));
  printf ("CFSR = 0x%x\n", (uint32_t)(*((volatile unsigned long *)(0xE000ED28))));
  printf ("HFSR = 0x%x\n", (uint32_t)(*((volatile unsigned long *)(0xE000ED2C))));
  printf ("DFSR = 0x%x\n", (uint32_t)(*((volatile unsigned long *)(0xE000ED30))));
  printf ("AFSR = 0x%x\n", (uint32_t)(*((volatile unsigned long *)(0xE000ED3C))));
  printf ("SCB_SHCSR = 0x%x\n", SCB->SHCSR);
  memstat ();

  while (1);
}


Цитата
Сталкивался с подобным. Помогло отключение, щас точно не помню, какого то буфера в камне. Вроде бы префеч ( ну или как его там ).

Попробую.
kan35
Возможно у вас в параллельных потоках используется FPU. В таком случае следует позаботиться о том, чтобы контекст FPU сохранялся при переключении задач (во freertos какой то флаг разрешения должен быть по идее). Если FPU используется в прерывании, то следует разрешить в процессору сохранять контекст в стек.
Самое простое и быстрое для проверки тезиса - отключить FPU в компиляторе.
kolobok0
Цитата(Quasar @ Jul 8 2014, 13:59) *
...Код вот такой:...


загляните в PM0214 стр.43, таблица 18. Что там я семёрки не вижу на хвосте. Возможно у нас разные доки конечно же...
Quasar
Цитата(kolobok0 @ Jul 9 2014, 02:12) *
загляните в PM0214 стр.43, таблица 18. Что там я семёрки не вижу на хвосте. Возможно у нас разные доки конечно же...


Я честно говоря не совсем понял, когда случается exception чего должно быть в LR? Адрес где случилось прерывание или 'EXC_RETURN values' где все биты с 32 по 5 единица? Или EXC_RETURN должен загрузиться в LR только после команд BX, LDM, POP?
Golikov A.
по идее в кортекс м3-м4 при в ходе в прерывание в lr всегда EXC_RETURN. Куда возвращаться выбирается из стэка по команде вернутся, вроде как...

Quasar
Цитата(kan35 @ Jul 8 2014, 20:12) *
Возможно у вас в параллельных потоках используется FPU. В таком случае следует позаботиться о том, чтобы контекст FPU сохранялся при переключении задач (во freertos какой то флаг разрешения должен быть по идее). Если FPU используется в прерывании, то следует разрешить в процессору сохранять контекст в стек.
Самое простое и быстрое для проверки тезиса - отключить FPU в компиляторе.

Идея правдободобная если учитывать тот факт, что у меня действительно два потока используют FPU, но в моей версии FreeRTOS, контекст переключается приведенной ниже функцией, там есть проверка на использование FPU:

Код
__asm void xPortPendSVHandler( void )
{
    extern uxCriticalNesting;
    extern pxCurrentTCB;
    extern vTaskSwitchContext;

    PRESERVE8

    mrs r0, psp

    /* Get the location of the current TCB. */
    ldr    r3, =pxCurrentTCB
    ldr    r2, [r3]

    /* Is the task using the FPU context?  If so, push high vfp registers. */
    tst r14, #0x10
    it eq
    vstmdbeq r0!, {s16-s31}

    /* Save the core registers. */
    stmdb r0!, {r4-r11, r14}

    /* Save the new top of stack into the first member of the TCB. */
    str r0, [r2]

    stmdb sp!, {r3}
    mov r0, #configMAX_SYSCALL_INTERRUPT_PRIORITY
    msr basepri, r0
    bl vTaskSwitchContext
    mov r0, #0
    msr basepri, r0
    ldmia sp!, {r3}

    /* The first item in pxCurrentTCB is the task top of stack. */
    ldr r1, [r3]
    ldr r0, [r1]

    /* Pop the core registers. */
    ldmia r0!, {r4-r11, r14}

    /* Is the task using the FPU context?  If so, pop the high vfp registers
    too. */
    tst r14, #0x10
    it eq
    vldmiaeq r0!, {s16-s31}

    msr psp, r0

    #ifdef WORKAROUND_PMU_CM001 /* XMC4000 specific errata */
        #if WORKAROUND_PMU_CM001 == 1
            push { r14 }
            pop { pc }
        #endif
    #endif

    bx r14
    nop
  nop
}



Golikov A.
А конвейеры учтены? Там есть же какие-то барьеры на этот счет.
Quasar
Цитата(Golikov A. @ Jul 9 2014, 17:25) *
А конвейеры учтены? Там есть же какие-то барьеры на этот счет.


А как и кем они должны учитываться? Вот здесь сказано только про регистры?
Golikov A.
Вот фиг знает кем. Есть мнение что программистом, но может и операционкой.

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

Я не утверждаю, просто человек выше писал что отключения прифетча помогало ему и так дале... Погуглите барьеры синхронизации данных, памяти, команд. Может натолкнетесь на что-то что вам сейчас очевидно должно быть более понятно, чем мне. У меня операционки сейчас ваще никакой нетsm.gif
kolobok0
Цитата(Quasar @ Jul 9 2014, 14:04) *
Я честно говоря не совсем понял,


когда вкуривал вопрос - натолкнулся на то, что под фрииртос при переключении контекста могут исползоваться разные стэки.
и если заюзать алгоритм который привели Вы, то можно не то долго и упорно анализировать (указатель стэка тупо банально ноль может быть).
на этом форуме нашёл упоминание того подхода, что описал выше. практика и даташит показал истину данного подхода.
хотя может у вас задача просто полазить по коду - тут тогда ой, я не прав...
adnega
Очень важно во FreeRTOS правильно указывать приоритеты прерываний (и вообще разрешить работу по приоритетам).
Тема обсуждалась на форуме.

Искать по ключевому слову "NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4)".
Quasar
Цитата
Сталкивался с подобным. Помогло отключение, щас точно не помню, какого то буфера в камне. Вроде бы префеч ( ну или как его там ).


Переразвел немного железку, увеличил стеки, перетащил работу FPU в один поток. Все равно продолжились вылеты. То NOCP, то Undefened Instruction. Отключил префтеч. буфер, HardFault'ы как рукой сняло.
jcxz
Это какой именно prefetch отключили? Интересно.
И действительно все fault-ы после этого прекратились?

PS: У Вас кстати LwIP плохо портирован (или вообще не портирован) на Cortex. Видно по куску кода в самом первом посте
(SWAP_BYTES_IN_WORD).
sidy
Скорее всего отключили буфер предварительной выборки Prefetch buffer: FLASH_ACR_PRFTEN. Сам сталкивался с тем что при включенном буфере программа попадает в HardFault, из произвольного места.
Quasar
Цитата(jcxz @ Oct 4 2014, 12:32) *
Это какой именно prefetch отключили? Интересно.
И действительно все fault-ы после этого прекратились?

PS: У Вас кстати LwIP плохо портирован (или вообще не портирован) на Cortex. Видно по куску кода в самом первом посте
(SWAP_BYTES_IN_WORD).


Отключил FLASH_ACR_PRFTEN. После этого, пока не было ни одного Hard_Fault. Я как-то и падения производительности не заметил. Сейчас 5 фильтров IIR использующих FPU крутятся и 50 частот обрабатывается алгоритмом Герцеля + Speex. Хватает еще и на сеть вполне.

По поводу оптимизации LwIP, это тот который в STM32Cube идет. То есть, я его ни как не правил, наверное его ни кто не оптимизировал под Cortex.
AHTOXA
Цитата(Quasar @ Oct 4 2014, 19:16) *
Отключил FLASH_ACR_PRFTEN.

У вас наверное ревизия A. Там не работает префетч, это описано в еррате.
В ревизии Z это исправили.
Я использовал вот такой код, чтобы включать префетч только в ревизии Z:
Код
    static const uint32_t REVISION_Z = 0x10010000;
    FLASH->ACR = 0
            | ((DBGMCU->IDCODE & DBGMCU_IDCODE_REV_ID) == REVISION_Z ? FLASH_ACR_PRFTEN : 0)
            | FLASH_ACR_ICEN
            | FLASH_ACR_DCEN
            | FLASH_ACR_LATENCY_5WS
        ;
scifi
Цитата(AHTOXA @ Oct 4 2014, 23:01) *
Я использовал вот такой код, чтобы включать префетч только в ревизии Z:

А зачем его включать, если и без него всё работает?
ataradov
QUOTE (scifi @ Jan 26 2016, 12:07) *
А зачем его включать, если и без него всё работает?

Чтобы работало быстрее? Без кешей тоже все работает и без любых других оптимизаций.
SasaVitebsk
Цитата(Quasar @ Oct 4 2014, 10:02) *
Переразвел немного железку, увеличил стеки, перетащил работу FPU в один поток. Все равно продолжились вылеты. То NOCP, то Undefened Instruction. Отключил префтеч. буфер, HardFault'ы как рукой сняло.

У меня FreeRTOS, LwIP, десяток задач, stm32f407. FPU в полный рост причём в очень многих задачах. Математики очень много. Всё работает ничего не вылетает. Так что ничего не надо переносить.
Гарантированные размеры стека настраиваются легко. Выберите режим, чтобы он заполнялся. дайте поработать да и посмотрите докуда доходит. FreeRTOS это позволяет сделать.
scifi
Цитата(ataradov @ Jan 26 2016, 22:07) *
Чтобы работало быстрее? Без кешей тоже все работает и без любых других оптимизаций.

В моей практике если "уже работает", ни разу не было "лучше бы быстрее". Даже наоборот - станешь ускорять, что-нибудь напутаешь и что-нибудь сломаешь. Это же не компьютерная игра, а embedded.
ataradov
QUOTE (scifi @ Jan 27 2016, 01:17) *
Даже наоборот - станешь ускорять, что-нибудь напутаешь и что-нибудь сломаешь.
Я не путаю и не ломаю. А чем дальше в лес, тем сложнее без наворотов. Cortex-M7 на 300 МГц без ускорений сильно тормозится.
Quasar
Цитата(SasaVitebsk @ Jan 27 2016, 09:16) *
У меня FreeRTOS, LwIP, десяток задач, stm32f407. FPU в полный рост причём в очень многих задачах. Математики очень много. Всё работает ничего не вылетает. Так что ничего не надо переносить.
Гарантированные размеры стека настраиваются легко. Выберите режим, чтобы он заполнялся. дайте поработать да и посмотрите докуда доходит. FreeRTOS это позволяет сделать.


У меня тоже все работает и ничего не вылетает, проблема была в префтече на ревизии А, собственно выше я так и написал.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.