Skip to main content
luke2
Associate III
February 26, 2016
Question

Hardfault with simple method call

  • February 26, 2016
  • 4 replies
  • 931 views
Posted on February 26, 2016 at 03:57

Hi all,

I am having an odd hard-fault crash on my STM32F030 board when I attempt to use USART. The calls are pretty standard, which leads me to believe its a linker issue. I have simplified to the minimal program that generates the fault, which is:

#include ''stm32f0xx.h''

#include ''stm32f0xx_rcc.h''

#include ''stm32f0xx_gpio.h''

#include ''stm32f0xx_usart.h''

void test(char* s) {

}

int main(void)

{

USART_InitTypeDef USART_InitStructure;

    USART_InitStructure.USART_BaudRate = 57600;//9600;

    USART_InitStructure.USART_WordLength = USART_WordLength_8b;

    USART_InitStructure.USART_StopBits = USART_StopBits_1;

    USART_InitStructure.USART_Parity = USART_Parity_No;

    USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;

    USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;

    USART_Init(USART1, &USART_InitStructure);

    USART_Cmd(USART1,ENABLE);

test(''test'');

    while(1)

    {

    }

}

Simply by calling test() with a literal string after calling USART_Init() generates the fault, which makes no sense to me. In debug the trace shows WWDG_IrqHandler() in the call stack, but I presume this just the last weak handler defined - the fault code is given as a hard-fault. This seems to be a linker issue but I cannot see what it may be, since the compile/link calls were auto-generated by CooCox and have always worked fine in the past. The compile/linker calls are:

arm-none-eabi-gcc -mcpu=cortex-m0 -mthumb -Wall -ffunction-sections -g -O0 -c -DSTM32F030R8T6 -DSTM32F030X8 -DUSE_STDPERIPH_DRIVER -D__ASSEMBLY__ -IC:\Test\stm32_lib\inc -IC:\ -IC:\Test -IC:\Test\cmsis_boot -IC:\Test\stm32_lib -IC:\Test\cmsis_core C:\Test\stm32_lib\src\stm32f0xx_rcc.c C:\Test\main.c C:\Test\cmsis_boot\startup\startup_stm32f0xx.s C:\Test\cmsis_boot\system_stm32f0xx_temp.c C:\Test\stm32_lib\src\stm32f0xx_gpio.c C:\Test\stm32_lib\src\stm32f0xx_usart.c C:\Test\stm32_lib\src\stm32f0xx_misc.c

arm-none-eabi-gcc -mcpu=cortex-m0 -mthumb -g -nostartfiles -Wl,-Map=test.map -O0 -Wl,--gc-sections -LC:\CooCox\CoIDE\configuration\ProgramData\test -Wl,-TC:\CooCox\CoIDE\configuration\ProgramData\test/arm-gcc-link.ld -g -o test.elf ..\obj\stm32f0xx_rcc.o ..\obj\main.o ..\obj\startup_stm32f0xx.o ..\obj\system_stm32f0xx_temp.o ..\obj\stm32f0xx_gpio.o ..\obj\stm32f0xx_usart.o ..\obj\stm32f0xx_misc.o

Any ideas?
    This topic has been closed for replies.

    4 replies

    Tesla DeLorean
    Guru
    February 26, 2016
    Posted on February 26, 2016 at 04:39

    Any ideas?

    Well you'd want to take a disassembly, and the registers at the faulting instruction, and understand just exactly what the processor is objecting too. Have a Hard Fault Handler to decompose it, and keep it away from the DefaultHandler.

    Based on what you've described I'm leaning toward an unaligned stack, or a sizing issue, probably coming from the linker script.

    Would suggest you attach the .ELF, .MAP and .LD files.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    luke2
    luke2Author
    Associate III
    February 26, 2016
    Posted on February 26, 2016 at 05:14

    Ok, the fault is occurring in the startup code here:

    CopyDataInit:

    ldr r3, =_sidata

    ldr r3, [r3, r1]

    str r3, [r0, r1]

    adds r1, r1, #4

    The second instruction triggers the hard fault, where r1=0x0, r3=0x0800076d(ldr of _sidata)

    I have attach the map, elf and ld files.

    Thanks for your help.

    ________________

    Attachments :

    arm-gcc-link.ld : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1BW&d=%2Fa%2F0X0000000bjX%2FzwtOe4F6A_Y7L3ZrlvbNs6OZRx15PBPnIhmq81xU6_w&asPdf=false

    test.map : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I17V&d=%2Fa%2F0X0000000bjV%2FOZ8gQFqLG5Q1b8_AYS_9ZG1AaNtiTZQL6WufZAliO68&asPdf=false
    Tesla DeLorean
    Guru
    February 26, 2016
    Posted on February 26, 2016 at 05:53

    Ok, so the linker script fails to do any alignment, if your string was ''abc'', ie 4 characters with the NUL, it probably wouldn't fail like this.

    Something like this

    ...
    .ARM.extab : 
    {
    . = ALIGN(4);
    *(.ARM.extab* .gnu.linkonce.armextab.*)
    } > rom 
    . = ALIGN(4);
    __exidx_start = .;
    .ARM.exidx :
    {
    *(.ARM.exidx* .gnu.linkonce.armexidx.*)
    } > rom 
    __exidx_end = .;
    . = ALIGN(4);
    __etext = .;
    /* _sidata is used in coide startup code */
    _sidata = __etext;
    .data : AT (__etext) /* aligned */
    {
    ...

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    luke2
    luke2Author
    Associate III
    February 26, 2016
    Posted on February 26, 2016 at 08:15

    Hmmm, odd since the script is auto generated by coocox and this hasn't happened previously. Perhaps I have configured CoIDE incorrectly somewhere? Do  you have any experience with it?

    Thanks again, much appreciated