Why does the controller (stm32l476rg) fall into hard fault?

Question:

I'm trying to run a program for blinking LEDs on STM32L476RG. The program is successfully flashed and launched. Initialization is in progress, but when the program jumps to main() I get a hard fault:

signal handler called () at 0xfffffff9

I use openocd for firmware. I use the libopencm3 library, so the linker script looks like this:

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

INCLUDE libopencm3_stm32l4.ld

The complete libopencm3_stm32l4.ld script is below.

/*
 * This file is part of the libopencm3 project.
 *
 * Copyright (C) 2009 Uwe Hermann <uwe@hermann-uwe.de>
 *
 * 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 <http://www.gnu.org/licenses/>.
 */

/* 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));

Compiler options:

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 …

Actually how can you localize the source of the problem? Where is the dog buried?

Answer:

First of all, open the finished binary file with a hexadecimal editor and see if the interrupt table is really located at the beginning of the program. In it, the first word should be equal to 0x20000000 + the size of the RAM – this is the stack pointer. Further words are interrupt pointers, and most likely, most of them should point to the same address – the address of the DefaultHandler label. It should look like approximately 0x0800…. If everything is in order, let's move on.

[hereinafter – guesses] There is a vector_table variable in the linker script, which is not assigned a value anywhere. Most likely, it is used in the starting assembler code of the program to copy the interrupt table to RAM, but since this variable has not been assigned a value, it is not clear where the copying takes place. It probably meant the following:

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

To determine exactly, you need to look at the assembler listings. Since you have a debugger, you can trace them and find the place where (possibly) copying occurs.

If this is not the case, you can also check the interrupt table to see if it really fits your controller.

Post Views: 14
Scroll to Top