|
STM32F417 вылетает в Hard Fault, NOCP |
|
|
|
Jul 7 2014, 14:42
|

Местный
  
Группа: Свой
Сообщений: 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 (см. приложенные картинки). Есть подозрения, что проблема аппаратная, так как, на втором экземпляре слёт случается сильно реже, но все равно случается. Но мне не ясно, почему именно на это инструкции вылетает исключение? Может кто посоветует направление, где искать?
|
|
|
|
|
Jul 8 2014, 05:45
|
практикующий тех. волшебник
    
Группа: Участник
Сообщений: 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
|
|
|
|
|
Jul 8 2014, 09:59
|

Местный
  
Группа: Свой
Сообщений: 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); } Цитата Сталкивался с подобным. Помогло отключение, щас точно не помню, какого то буфера в камне. Вроде бы префеч ( ну или как его там ). Попробую.
|
|
|
|
|
Jul 9 2014, 11:50
|

Местный
  
Группа: Свой
Сообщений: 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 }
|
|
|
|
|
Jul 9 2014, 14:50
|

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

|
Цитата(Golikov A. @ Jul 9 2014, 17:25)  А конвейеры учтены? Там есть же какие-то барьеры на этот счет. А как и кем они должны учитываться? Вот здесь сказано только про регистры?
|
|
|
|
|
Jul 9 2014, 18:59
|
Гуру
     
Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454

|
Вот фиг знает кем. Есть мнение что программистом, но может и операционкой. Там есть команды - барьеры всякой синхронизации, которые гарантируют что все схемы предварительного выбора команд отработали и встали. Есть вероятность что я несу бред, потому что с FreeRTOS знаком посредственно, но может так оказаться что когда у вас условно один поток проверяет не занято ли FPU оно может быть не занято, но команды обращения в него уже выбраны и один поток начнет работать, а другой будет дорабатывать эти команды и будет колапс. Ну или что-то вроде. Я не утверждаю, просто человек выше писал что отключения прифетча помогало ему и так дале... Погуглите барьеры синхронизации данных, памяти, команд. Может натолкнетесь на что-то что вам сейчас очевидно должно быть более понятно, чем мне. У меня операционки сейчас ваще никакой нет
|
|
|
|
|
Jul 10 2014, 06:11
|
практикующий тех. волшебник
    
Группа: Участник
Сообщений: 1 190
Регистрация: 9-09-05
Пользователь №: 8 417

|
Цитата(Quasar @ Jul 9 2014, 14:04)  Я честно говоря не совсем понял, когда вкуривал вопрос - натолкнулся на то, что под фрииртос при переключении контекста могут исползоваться разные стэки. и если заюзать алгоритм который привели Вы, то можно не то долго и упорно анализировать (указатель стэка тупо банально ноль может быть). на этом форуме нашёл упоминание того подхода, что описал выше. практика и даташит показал истину данного подхода. хотя может у вас задача просто полазить по коду - тут тогда ой, я не прав...
Сообщение отредактировал kolobok0 - Jul 10 2014, 06:15
|
|
|
|
|
Oct 4 2014, 07:02
|

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

|
Цитата Сталкивался с подобным. Помогло отключение, щас точно не помню, какого то буфера в камне. Вроде бы префеч ( ну или как его там ). Переразвел немного железку, увеличил стеки, перетащил работу FPU в один поток. Все равно продолжились вылеты. То NOCP, то Undefened Instruction. Отключил префтеч. буфер, HardFault'ы как рукой сняло.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|