2011-08-22 10:05 PM
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-hardfault2011-08-23 06:30 AM
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 0x20004FE02011-08-24 09:28 PM
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.
2011-08-27 11:56 PM
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...2011-08-28 05:04 AM
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.2011-08-28 08:32 AM
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.2012-03-22 05:19 PM
2012-03-22 07:07 PM
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?2012-03-23 08:25 AM