Перейти к содержанию
Поиск
    

STM32F417 вылетает в Hard Fault

Ответить

Quasar    20

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 (см. приложенные картинки).

 

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

 

post-23021-1404742143_thumb.png

post-23021-1404742154_thumb.png

post-23021-1404742167_thumb.png

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

vlad_new    1

vlad_new
Опубликовано · Жалоба

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

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

kolobok0    0

kolobok0
Опубликовано (изменено) · Жалоба
Есть самодельная плата на 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);
    }

 

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

Изменено пользователем kolobok0

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

Quasar    20

Quasar
Опубликовано · Жалоба
приблизительно такой-же фарш. Пока "проблемы по железу" всегда упирались в софт. Т.е. обычно из-за

невнятной(читай раскиданной по многим источникам) документации (последнее из этой оперы было - оконный вачдог + его 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    7

kan35
Опубликовано · Жалоба

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

Самое простое и быстрое для проверки тезиса - отключить FPU в компиляторе.

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

kolobok0    0

kolobok0
Опубликовано · Жалоба
...Код вот такой:...

 

загляните в PM0214 стр.43, таблица 18. Что там я семёрки не вижу на хвосте. Возможно у нас разные доки конечно же...

 

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

Quasar    20

Quasar
Опубликовано · Жалоба
загляните в PM0214 стр.43, таблица 18. Что там я семёрки не вижу на хвосте. Возможно у нас разные доки конечно же...

 

Я честно говоря не совсем понял, когда случается exception чего должно быть в LR? Адрес где случилось прерывание или 'EXC_RETURN values' где все биты с 32 по 5 единица? Или EXC_RETURN должен загрузиться в LR только после команд BX, LDM, POP?

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

Golikov    0

Golikov
Опубликовано · Жалоба

по идее в кортекс м3-м4 при в ходе в прерывание в lr всегда EXC_RETURN. Куда возвращаться выбирается из стэка по команде вернутся, вроде как...

 

 

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

Quasar    20

Quasar
Опубликовано · Жалоба
Возможно у вас в параллельных потоках используется 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
}

 

 

 

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

Quasar    20

Quasar
Опубликовано · Жалоба
А конвейеры учтены? Там есть же какие-то барьеры на этот счет.

 

А как и кем они должны учитываться? Вот здесь сказано только про регистры?

 

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

Golikov    0

Golikov
Опубликовано · Жалоба

Вот фиг знает кем. Есть мнение что программистом, но может и операционкой.

 

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

 

Я не утверждаю, просто человек выше писал что отключения прифетча помогало ему и так дале... Погуглите барьеры синхронизации данных, памяти, команд. Может натолкнетесь на что-то что вам сейчас очевидно должно быть более понятно, чем мне. У меня операционки сейчас ваще никакой нет:)

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

kolobok0    0

kolobok0
Опубликовано (изменено) · Жалоба
Я честно говоря не совсем понял,

 

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

и если заюзать алгоритм который привели Вы, то можно не то долго и упорно анализировать (указатель стэка тупо банально ноль может быть).

на этом форуме нашёл упоминание того подхода, что описал выше. практика и даташит показал истину данного подхода.

хотя может у вас задача просто полазить по коду - тут тогда ой, я не прав...

Изменено пользователем kolobok0

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

adnega    11

adnega
Опубликовано · Жалоба

Очень важно во FreeRTOS правильно указывать приоритеты прерываний (и вообще разрешить работу по приоритетам).

Тема обсуждалась на форуме.

 

Искать по ключевому слову "NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4)".

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

Quasar    20

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

 

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

Поделиться сообщением

Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

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

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
×
  • Создать...