Hardfault with simple method call

luke2 · ‎2016-02-25

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?

Tesla DeLorean · ‎2016-02-25

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
Up vote any posts that you find helpful, it shows what's working..

luke2 · ‎2016-02-25

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 · ‎2016-02-25

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
Up vote any posts that you find helpful, it shows what's working..

luke2 · ‎2016-02-25

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