реклама на сайте
подробности

 
 
2 страниц V   1 2 >  
Reply to this topicStart new topic
> STM32F417 вылетает в Hard Fault, NOCP
Quasar
сообщение Jul 7 2014, 14:42
Сообщение #1


Местный
***

Группа: Свой
Сообщений: 257
Регистрация: 2-12-06
Из: Default City
Пользователь №: 23 021



Приветствую.

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

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

Прикрепленное изображение

Прикрепленное изображение

Прикрепленное изображение
Go to the top of the page
 
+Quote Post
vlad_new
сообщение Jul 7 2014, 16:16
Сообщение #2


Местный
***

Группа: Участник
Сообщений: 218
Регистрация: 24-06-10
Пользователь №: 58 127



Сталкивался с подобным. Помогло отключение, щас точно не помню, какого то буфера в камне. Вроде бы префеч ( ну или как его там ).
Go to the top of the page
 
+Quote Post
kolobok0
сообщение Jul 8 2014, 05:45
Сообщение #3


практикующий тех. волшебник
*****

Группа: Участник
Сообщений: 1 190
Регистрация: 9-09-05
Пользователь №: 8 417



Цитата(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);
    }


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

Сообщение отредактировал kolobok0 - Jul 8 2014, 05:56
Go to the top of the page
 
+Quote Post
Quasar
сообщение Jul 8 2014, 09:59
Сообщение #4


Местный
***

Группа: Свой
Сообщений: 257
Регистрация: 2-12-06
Из: Default City
Пользователь №: 23 021



Цитата(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);
}


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

Попробую.
Go to the top of the page
 
+Quote Post
kan35
сообщение Jul 8 2014, 16:12
Сообщение #5


Знающий
****

Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594



Возможно у вас в параллельных потоках используется FPU. В таком случае следует позаботиться о том, чтобы контекст FPU сохранялся при переключении задач (во freertos какой то флаг разрешения должен быть по идее). Если FPU используется в прерывании, то следует разрешить в процессору сохранять контекст в стек.
Самое простое и быстрое для проверки тезиса - отключить FPU в компиляторе.
Go to the top of the page
 
+Quote Post
kolobok0
сообщение Jul 8 2014, 22:12
Сообщение #6


практикующий тех. волшебник
*****

Группа: Участник
Сообщений: 1 190
Регистрация: 9-09-05
Пользователь №: 8 417



Цитата(Quasar @ Jul 8 2014, 13:59) *
...Код вот такой:...


загляните в PM0214 стр.43, таблица 18. Что там я семёрки не вижу на хвосте. Возможно у нас разные доки конечно же...
Go to the top of the page
 
+Quote Post
Quasar
сообщение Jul 9 2014, 10:04
Сообщение #7


Местный
***

Группа: Свой
Сообщений: 257
Регистрация: 2-12-06
Из: Default City
Пользователь №: 23 021



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


Я честно говоря не совсем понял, когда случается exception чего должно быть в LR? Адрес где случилось прерывание или 'EXC_RETURN values' где все биты с 32 по 5 единица? Или EXC_RETURN должен загрузиться в LR только после команд BX, LDM, POP?
Go to the top of the page
 
+Quote Post
Golikov A.
сообщение Jul 9 2014, 10:22
Сообщение #8


Гуру
******

Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454



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

Go to the top of the page
 
+Quote Post
Quasar
сообщение Jul 9 2014, 11:50
Сообщение #9


Местный
***

Группа: Свой
Сообщений: 257
Регистрация: 2-12-06
Из: Default City
Пользователь №: 23 021



Цитата(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
}



Go to the top of the page
 
+Quote Post
Golikov A.
сообщение Jul 9 2014, 13:25
Сообщение #10


Гуру
******

Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454



А конвейеры учтены? Там есть же какие-то барьеры на этот счет.
Go to the top of the page
 
+Quote Post
Quasar
сообщение Jul 9 2014, 14:50
Сообщение #11


Местный
***

Группа: Свой
Сообщений: 257
Регистрация: 2-12-06
Из: Default City
Пользователь №: 23 021



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


А как и кем они должны учитываться? Вот здесь сказано только про регистры?
Go to the top of the page
 
+Quote Post
Golikov A.
сообщение Jul 9 2014, 18:59
Сообщение #12


Гуру
******

Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454



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

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

Я не утверждаю, просто человек выше писал что отключения прифетча помогало ему и так дале... Погуглите барьеры синхронизации данных, памяти, команд. Может натолкнетесь на что-то что вам сейчас очевидно должно быть более понятно, чем мне. У меня операционки сейчас ваще никакой нетsm.gif
Go to the top of the page
 
+Quote Post
kolobok0
сообщение Jul 10 2014, 06:11
Сообщение #13


практикующий тех. волшебник
*****

Группа: Участник
Сообщений: 1 190
Регистрация: 9-09-05
Пользователь №: 8 417



Цитата(Quasar @ Jul 9 2014, 14:04) *
Я честно говоря не совсем понял,


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

Сообщение отредактировал kolobok0 - Jul 10 2014, 06:15
Go to the top of the page
 
+Quote Post
adnega
сообщение Jul 10 2014, 06:22
Сообщение #14


Гуру
******

Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702



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

Искать по ключевому слову "NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4)".
Go to the top of the page
 
+Quote Post
Quasar
сообщение Oct 4 2014, 07:02
Сообщение #15


Местный
***

Группа: Свой
Сообщений: 257
Регистрация: 2-12-06
Из: Default City
Пользователь №: 23 021



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


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

2 страниц V   1 2 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 24th July 2025 - 09:19
Рейтинг@Mail.ru


Страница сгенерированна за 0.01501 секунд с 7
ELECTRONIX ©2004-2016