[Handler HardFault] About downloading maple.bin with openocd(jlink)

LeafLabs Garden » Development

[Handler HardFault] About downloading maple.bin with openocd(jlink)

(5 posts) (2 voices)

Started 4 years ago by librae8226
Latest reply from librae8226

librae8226
Member

Hi, I am attracted by the architecture of libmaple, so planning to try it on my board (stm32f103rbt6). However, it comes up with a Handler HardFault while downloading use openocd.
Here is my steps:
--------------------------------------------------
$ git clone git://github.com/leaflabs/libmaple.git
$ cd libmaple
$ cp main.cpp.example main.cpp
$ make flash
--------------------------------------------------

Because I am using jlink, then I modified support/openocd/flash_0.4.cfg as:
$ git diff
diff --git a/support/openocd/flash_0.4.cfg b/support/openocd/flash_0.4.cfg
index 32c06c6..d99c48c 100644
--- a/support/openocd/flash_0.4.cfg
+++ b/support/openocd/flash_0.4.cfg
@@ -1,9 +1,10 @@
# script for stm32

-interface ft2232
-ft2232_device_desc "Olimex OpenOCD JTAG"
-ft2232_layout olimex-jtag
-ft2232_vid_pid 0x15ba 0x0003
+interface jlink
+#interface ft2232
+#ft2232_device_desc "Olimex OpenOCD JTAG"
+#ft2232_layout olimex-jtag
+#ft2232_vid_pid 0x15ba 0x0003

After that, do
$ openocd -f support/openocd/flash_0.4.cfg

Results below is printed
------------------------
Open On-Chip Debugger 0.4.0 (2011-02-09-04:28)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
1000 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
srst_only separate srst_gates_jtag srst_open_drain
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link ARM V7 compiled Jun 30 2009 11:05:27
Info : JLink caps 0xb9ff7bbf
Info : JLink hw version 70000
Info : JLink max mem block 9152
Info : Vref = 3.377 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0

Info : J-Link JTAG Interface ready
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
Warn : stm32.cpu -- clearing lockup after double fault
Halting...
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08007844 msp: 0x20005000
Unlocking flash...
Info : device id = 0x20036410
Info : flash size = 128kbytes
cleared protection for sectors 0 through 127 on flash bank 0
Erasing...
erased address 0x08000000 (length 131072) in 0.040999s (3122.027 kb/s)
Flashing image...
wrote 13136 bytes from file build/maple.bin to flash bank 0 at offset 0x00000000 in 0.924966s (13.869 kb/s)
Verifying image...
verified 13136 bytes in 0.529968s (24.205 kb/s)
Checksum verified, resetting chip
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Warn : stm32.cpu -- clearing lockup after double fault
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0x08007064 msp: 0x20004fe0
Daemon shutdown
shutdown command invoked
------------------------

So, I don't know what on earth resulted in this. Something wrong about using openocd? Or linkerscripts? Need maple-bootloader? Any ideas?

Thanks a lot.
Support your excellent works as before. :P

Posted 4 years ago #
librae8226
Member

I tried to download flash step by step with openocd:

========================================================================
> init
> targets
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* stm32.cpu cortex_m3 little stm32.cpu running
> reset halt
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080000d4 msp: 0x20000100
> flash erase_address 0x08000000 0x20000
erased address 0x08000000 (length 131072) in 0.038003s (3368.155 kb/s)
> flash write_image maple.bin 0x08000000 bin
not enough working area available(requested 16384, free 16336)
wrote 13136 bytes from file maple.bin in 1.157949s (11.078 kb/s)
> verify_image maple.bin 0x08000000 bin
verified 13136 bytes in 0.528980s (24.251 kb/s)
> reset halt
JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08007844 msp: 0x20005000
> resume
stm32.cpu -- clearing lockup after double fault
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0x08007064 msp: 0x20004fe0
>

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

in maple.map:

.text 0x08007060 0x60 build/./libmaple/exc.o
0x08007060 __exc_nmi
0x08007064 __exc_hardfault
0x08007068 __exc_memmanage
0x0800706c __exc_busfault
0x08007070 __exc_usagefault

...

.text 0x08007844 0x10 ./support/ld/libcs3_stm32_med_density.a(start.o)
0x08007844 _start
.text 0x08007854 0x108 ./support/ld/libcs3_stm32_med_density.a(start_c.o)
0x08007854 __cs3_start_c
========================================================================

According to above information, I find that after "flash write_image" & "verify_image", "reset halt", the "pc: 0x08007844" is no problem, exactly the "_start" entry point.
But just after that I try "resume" or "reset run", it went into HardFault straight forward.

????

Posted 4 years ago #
librae8226
Member

Solved.

For building target, it should be:
$ make jtag

Posted 4 years ago #
poslathian
LeafLabs

glad you solved your problem. Make JTAG will treat your code as totally first class and link it against the base address of 0x00, which means whatever goes into a make jtag binary gets located in memory right at 0x0. Whereas with make ram and make flash your binary will be offset by some amount, to leave room for the bootloader. The bootloader is then responsible for jumping out to this offset.

Posted 4 years ago #
librae8226
Member

@poslathian

Yeah, I was careless of looking into the linker script.. :P

Thanks a lot, carry on with your excellent products!

Posted 4 years ago #

RSS feed for this topic

Reply

You must log in to post.