Почему контроллер (stm32l476rg) падает в hard fault?

#c #embedded #stm32

Пытаюсь запустить программу моргания светодиодами на STM32L476RG. Программа успешно
прошивается и запускается. Выполняется начальная инициализация, но когда программа
делает переход на main() -- получаю hard fault:


  signal handler called () at 0xfffffff9


Для прошивки использую openocd. Использую библиотеку libopencm3, поэтому скрипт линкера
выглядит так:

MEMORY
{
   rom (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
   ram (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

INCLUDE libopencm3_stm32l4.ld


Полный скрипт libopencm3_stm32l4.ld ниже.

/*
 * This file is part of the libopencm3 project.
 *
 * Copyright (C) 2009 Uwe Hermann 
 *
 * This library is free software: you can redistribute it and/or modify
 * it under the terms of the GNU Lesser General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public License
 * along with this library.  If not, see .
 */

/* Generic linker script for STM32 targets using libopencm3. */

/* Memory regions must be defined in the ld script which includes this one. */

/* Enforce emmition of the vector table. */
EXTERN (vector_table)

/* Define the entry point of the output file. */
ENTRY(reset_handler)

/* Define sections. */
SECTIONS
{
    .text : {
        *(.vectors) /* Vector table */
        *(.text*)   /* Program code */
        . = ALIGN(4);
        *(.rodata*) /* Read-only data */
        . = ALIGN(4);
    } >rom

    /* C++ Static constructors/destructors, also used for __attribute__
     * ((constructor)) and the likes */
    .preinit_array : {
        . = ALIGN(4);
        __preinit_array_start = .;
        KEEP (*(.preinit_array))
        __preinit_array_end = .;
    } >rom
    .init_array : {
        . = ALIGN(4);
        __init_array_start = .;
        KEEP (*(SORT(.init_array.*)))
        KEEP (*(.init_array))
        __init_array_end = .;
    } >rom
    .fini_array : {
        . = ALIGN(4);
        __fini_array_start = .;
        KEEP (*(.fini_array))
        KEEP (*(SORT(.fini_array.*)))
        __fini_array_end = .;
    } >rom

    /*
     * Another section used by C++ stuff, appears when using newlib with
     * 64bit (long long) printf support
     */
    .ARM.extab : {
        *(.ARM.extab*)
    } >rom
    .ARM.exidx : {
        __exidx_start = .;
        *(.ARM.exidx*)
        __exidx_end = .;
    } >rom

    . = ALIGN(4);
    _etext = .;

    .data : {
        _data = .;
        *(.data*)   /* Read-write initialized data */
        . = ALIGN(4);
        _edata = .;
    } >ram AT >rom
    _data_loadaddr = LOADADDR(.data);

    .bss : {
        *(.bss*)    /* Read-write zero initialized data */
        *(COMMON)
        . = ALIGN(4);
        _ebss = .;
    } >ram

    /*
     * The .eh_frame section appears to be used for C++ exception handling.
     * You may need to fix this if you're using C++.
     */
    /DISCARD/ : { *(.eh_frame) }

    . = ALIGN(4);
    end = .;
}

PROVIDE(_stack = ORIGIN(ram) + LENGTH(ram));


Параметры компилятора:


  arm-none-eabi-g++ -mcpu=cortex-m4 -march=armv7e-m -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16
-munaligned-access -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections
-g3 ...


Собственно как можно локализировать источник проблемы? Где собака зарыта?
    

Ответы

Ответ 1

В первую очередь откройте шестнадцатеричным редактором готовый бинарный файл и посмотрите,
действительно ли в начале программы расположена таблица прерываний. В ней первое слово
должно быть равно 0x20000000 + размер оперативной памяти - это указатель стека. Дальнейшие
слова - указатели прерываний, и скорее всего, большинство из них должны указывать на
один и тот же адрес - адрес метки DefaultHandler. Он должен иметь вид приблизительно
0x0800.... Если всё в порядке, идём дальше.

[далее - догадки] В скрипте линкера присутствует переменная vector_table, которой
нигде не присваивается значение. Скорее всего, она используется в стартовом ассемблерном
коде программы для копирования таблицы прерываний в оперативную память, но так как
этой переменной не присвоено значение, копирование происходит непонятно куда. Скорее
всего, подразумевалось следующее:

.text : {
    vector_table = .
    *(.vectors) /* Vector table */
    *(.text*)   /* Program code */
    . = ALIGN(4);
    *(.rodata*) /* Read-only data */
    . = ALIGN(4);
} >rom


Чтобы определить точно, нужно смотреть ассемблерные листинги. Поскольку вы располагаете
отладчиком, вы можете их протрассировать и найти место, где (возможно) происходит копирование.

Если причина не в этом, можно также проверить таблицу прерываний, действительно ли
она подходит вашему контроллеру.


Ответ 2

В основном эта ошибка возникает при неправильной работе с памятью (обращение за границу
допустимой области памяти).

Надо убедиться, что:


размер стека достаточен;
не используется неинициализированный указатель.


Ответ 3

Возможные причины HardFault:


Debugging a HardFault on Cortex-M
Cortex-M3 / M4 Hard Fault Handler


Методы отладки:


Debugging a Hard Fault
Debugging Hard Fault & Other Exceptions  on ARM Cortex-M3 and ARM
Cortex-M4 microcontrollers
Debugging Hard Faults on ARM Cortex-M
Developing a Generic Hard Fault handler for ARM
Cortex-M3/Cortex-M4


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