The dreaded handler hardfault on new build chain

[aloerchner]

Posted on August 23, 2011 at 07:05

Greetings,

I am new to the STM32 family of devices and am trying to build for the FUTURELEC STM32 Stamp Board, which has on it the stm32f103ret6 processor. Link:

http://www.futurlec.com/ET-STM32_Stamp.shtml

I am able to build and flash the binary image, but immediately receive the HANDLER HARDFAULT message upon running the code. I have futzed around with this for about a week and pretty well out of ideas. Any help would be appreciated.

I am building on UBUNTU 10.04, using the latest CodeSourcery release, and the latest (3.5.0)release of the ST libraries. For flashing I use the Olimex ARM-USB-TINY with OpenOCD.

I set up the project environment using the guide supplied on this page, and followed the instructions to the letter:

http://stm32.spacevs.com/index.php?option=com_content&view=featured&Itemid=101

This guide uses the 3.3.0 version of the libraries. The necessary changes were made to reference the current 3.5.0 libraries.

Compiler output:

-----------------------------------------------------------------------------------

/usr/bin/make -C libs libs

make[1]: Entering directory `/home/.../MotionController_5_Phase_CORTEX/libs'

Building libstm32.a ...done.

make[1]: Leaving directory `/home/.../MotionController_5_Phase_CORTEX/libs'

/usr/bin/make -C src src

make[1]: Entering directory `/home/.../MotionController_5_Phase_CORTEX/src'

make[1]: Nothing to be done for `src'.

make[1]: Leaving directory `/home/.../MotionController_5_Phase_CORTEX/src'

arm-none-eabi-gcc -o main.elf -O3 -g -mcpu=cortex-m3 -mthumb -fno-exceptions -ffunction-sections -fdata-sections -L/home/.../MotionController_5_Phase_CORTEX/libs -nostartfiles -Wl,--gc-sections,-Tlinker.ld -Wl,--whole-archive src/app.a -Wl,--no-whole-archive -lm -lstm32

arm-none-eabi-objcopy -O ihex    main.elf main.hex

arm-none-eabi-objcopy -O binary main.elf main.bin

I replaced the path between ''home/'' and ''/MotionController_5_Phase_CORTEX'' with ''...'' for this email. Output of the flash operation and execution is as follows:

>

> flash write_image erase /home/.../MotionController_5_Phase_CORTEX/main.bin 0x8000000

auto erase enabled

wrote 1352 byte from file /home/.../MotionController_5_Phase_CORTEX/main.bin in 0.272857s (4.838844 kb/s)

>

> reset run                                                                                                                                                      

JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

target state: halted

target halted due to breakpoint, current mode: Handler HardFault

xPSR: 0x00000003 pc: 0x20000004 msp: 0x20004fe0

>

Register listing is:

> reg

===== arm v7m registers

(0) r0 (/32): 0x20000578

(1) r1 (/32): 0x08000548

(2) r2 (/32): 0x00000000

(3) r3 (/32): 0x00000023

(4) r4 (/32): 0x40022010

(5) r5 (/32): 0x4002200C

(6) r6 (/32): 0xE000E000

(7) r7 (/32): 0x20004FE0

(8) r8 (/32): 0xFFDEFFFE

(9) r9 (/32): 0xFFEFED79

(10) r10 (/32): 0xF07AC9EE

(11) r11 (/32): 0x01001EB3

(12) r12 (/32): 0xFF7FDFFF

(13) sp (/32): 0x20004FE0

(14) lr (/32): 0xFFFFFFF9

(15) pc (/32): 0x20000004

(16) xPSR (/32): 0x00000003

(17) msp (/32): 0x20004FE0

(18) psp (/32): 0x7B621F90

(19) primask (/1): 0x00

(20) basepri (/8): 0x00

(21) faultmask (/1): 0x00

(22) control (/2): 0x00

>

Any ideas what I'm doing wrong?

Thanks in advance.

#handler-hardfault

[Tesla DeLorean]

Posted on August 23, 2011 at 15:30

You'll have to look at the code it's executing. Disassemble it, understand it. GCC should have objdump.

Why for instance is the PC pointing to code in RAM?

What is the stacked state of the processor? LR reflects the fault handler return address, so perhaps you need to look at the stacked state to figure out what the real PC/LR values are for the fault. Dump the data at 0x20004FE0

[infoinfo989]

Posted on August 25, 2011 at 06:28

You might also want to try starting out with something simpler to build confidence. Maybe start off  with a simple blink-LED program or a ''hello world'' program, before diving in to your full-fledged application.

[aloerchner]

Posted on August 28, 2011 at 08:56

Thanks for the comments. I did start with the Blinky example from website:

http://gandalf.arubi.uni-kl.de/avr_projects/arm_projects/index_cortex.html#stm32_blink

and used this as the basis of the development. From here I began porting my existing 8-bit processor code and coming up to speed on the STM32 chip as I ported functions. These functions used a number of interrupts, timers, USARTS, etc, and all seemed to go well. 

Problems started when I began working with double precision variables or string functions, and I began getting the 'Handler Hardfault'  issues. I tried reverting back to the original Blink example from the website, declared two type double variables, and added them together. This immediately caused the the HardFault to occur. 

This just feels like one of those problems where I'm missing a fundamental principal. 

Again, any direction for this lost soul would be much appreciated...

[Tesla DeLorean]

Posted on August 28, 2011 at 14:04

You should look into getting the hard fault handler working to identify the faulting instructions. When it faults look at the stack content. When you know where you are you won't be so lost.

Joseph Yiu has published some Hard Fault routines to help decode the stack state.

The use of floating point (float/double) is going to require the addition of library code. Make sure that you have suitable command line options, and library files. One of the quickest ways to Hard Fault on the Cortex-M3 is to try running 32-bit ARM code. Look at the MAP file an see what has been pulled in by the linker.

Does it occur when you do the math, or when you use printf/scanf? The latter can be a problem for non-GCC compilers because often the stack is too small. Sounds like just the math, which will be calling some library code, probably the wrong one.

Use objdump to disassemble your code, identify where it is doing the floating point math, in a simple example app it should be easy enough to find.

[aloerchner]

Posted on August 28, 2011 at 17:32

Thanks clive1, These Hard Fault routines sound like a good way to go. This problem occurs for math, and also basic string functions such as strcpy, strcat, etc.

Thanks again for your help. I'll keep digging.

[stephen5489]

Posted on March 23, 2012 at 01:19

hi, I'm try to send data from stm32 to the hyperterminal and I can't do it, I've looked for a lot of examples but didn't works, I'm work with coocox and Keil uVision3, thanks in advance, this is the main code in coocox.

#include ''stm32f10x_gpio.h''

#include ''stm32f10x_i2c.h''

#include ''stm32f10x_rcc.h''

#include ''stm32f10x_usart.h''

#include ''stm32f10x_conf.h''

USART_InitTypeDef USART_InitTypeDef1={

115200,

USART_WordLength_8b,

USART_StopBits_1,

USART_Parity_No,

(USART_Mode_Rx | USART_Mode_Tx ),

USART_HardwareFlowControl_None

};

void uart_init(){

RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO | RCC_APB2Periph_GPIOA |  RCC_APB2Periph_USART1,ENABLE);

GPIO_InitTypeDef GPIO_InitStructure;

GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;

GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9;

GPIO_Init(GPIOA, &GPIO_InitStructure);

GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;

GPIO_InitStructure.GPIO_Pin = GPIO_Pin_10;

GPIO_Init(GPIOA, &GPIO_InitStructure);

USART_Init(USART1,&USART_InitTypeDef1);

USART_Cmd(USART1,ENABLE);

}

int main(void)

{

uart_init();

printf(''Welcome!\r\n'');

    while(1)

    {

    }

}

void PrintChar(char c){

while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET);//verifica se está desocupado

USART_SendData(USART1,c & 0x1FF); //transmite

}

void USART3_IRQHandler(){

}

[Tesla DeLorean]

Posted on March 23, 2012 at 03:07

This doesn't seem like an appropriate thread for this.

I'm not familiar with CooCox but the code doesn't look too bad. Why don't you step through it with a debugger? Or call the character function explicitly, are you sure printf() will be retargeted/hosted like this?

[stephen5489]

Posted on March 23, 2012 at 16:25

I'll bear in mind your recommendation, but I've did it on this way and using the stdio library and dosen't work neither, Do you know web sites where can I find information or examples about ports managment of STM32? thanks again.