2015-10-09 2 views
0

У меня возникли трудности с созданием жесткого обработчика ошибок для NRF51 с ARM CortexM0.Устранение неполадок - Arm Cortex-M0

(примечание: следующий код был совмещен из различных источников в Интернете) Вот что я до сих пор:

static void hard_fault_handler_c(unsigned int * hardfault_args) 
{ 
    unsigned int stacked_r0; 
    unsigned int stacked_r1; 
    unsigned int stacked_r2; 
    unsigned int stacked_r3; 
    unsigned int stacked_r12; 
    unsigned int stacked_lr; 
    unsigned int stacked_pc; 
    unsigned int stacked_psr; 

    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]); 

    for(;;); 
} 

void HardFault_Handler(void) 
{ 
    asm volatile( 
     "movs r0, #4\t\n" 
     "mov r1, lr\t\n" 
     "tst r0, r1\t\n" /* Check EXC_RETURN[2] */ 
     "beq 1f\t\n" 
     "mrs r0, psp\t\n" 
     "ldr r1,=hard_fault_handler_c\t\n" 
     "bx r1\t\n" 
     "1:mrs r0,msp\t\n" 
     "ldr r1,=hard_fault_handler_c\t\n" 
     : /* no output */ 
     : /* no input */ 
     : "r0" /* clobber */ 
    ); 
} 

ошибка во время компиляции является следующее: цель постройки: project.elf Вызывающие: Cross ARM C++ Linker C: \ Users \ Steven \ AppData \ Local \ Temp \ ccuAgDyP.ltrans9.ltrans.o: В функции HardFault_Handler': <artificial>:(.text.HardFault_Handler+0x18): undefined reference to hard_fault_handler_c» collect2.exe: ошибка: л.д. возвращается 1 Статус выхода марки: * ** [FruityMesh.elf] Ошибка 1 makefile: 65: r ecipe для target 'project.elf' failed

Таким образом, похоже, что у компоновщика возникли проблемы с поиском адреса для функции hard_fault_handler_c. Я бы подумал, что мне нужно будет написать сборку для импорта или включить путь к этой функции, но это только мое предложение. Я не смог написать сборку для M0, которая компилируется для этого.

Спасибо

+3

Почему он объявлен как «статический»? Что делать, если вы удалите его? Возможно, встроенная сборка интерпретируется как другая единица перевода. –

+2

Почему компилятор экспортирует символ для статической функции, которая, насколько это возможно, полностью не используется? Возможно, он даже полностью оптимизировал его. Управление потоком, подобное внутри встроенного asm, не является чем-то, что вы должны: a) ожидать работы, и б) когда-либо делать. Нет никакой веской причины не писать эту логику управления в C anway; у вас есть не более 3 инструкций, которым могут потребоваться инструкции asm для захвата соответствующего специального регистра в переменную C (если у вас нет подходящих свойств). – Notlikethat

+0

Посмотрите на свой файл карты и посмотрите, какие символы сгенерированы. Почти наверняка «статический» вызывает эту функцию, чтобы не иметь глобального символа (или искаженного глобального символа) –

ответ

0

Я хотел бы предложить обновление до version 11 в NRF SDK, который добавляет встроенную поддержку для жесткого обработчике ошибок (см nRF5_SDK_11.0.0_89a8197/компоненты/библиотеки/hardfault).

Смежные вопросы