I'm using Eclipse (Kepler release) GCC ARM Tools 4.7 OpenOCD 0.7.0
Its not clear how I can setup the Debug Configuration in order to ensure a Reset. Currently the Stack point is not being reset to the value of _estack in g_pfnVectors and on clicking on "Debug" the program counter is at the Reset Handler and SP = 0x00000000
I am presuming that I need to place some commands in the Initialization Commands but it's not clear what.
Can anyone help?
See if you can get the linker to spit out the load file it's using. It should be defining a section for vectors at the start of memory. On the Cortex cores, the stack pointer gets loaded on reset from memory location
0, the reset vector from 0x04, then all the other vectors in the table.Before you even run, look at memory location 0 and 0x04. If you don't see the address of the top of RAM followed by the address of the start of code (with bit 0 set, so the thing knows it's Thumb code and doesn't barf), then you've already diagnosed enough problems that you don't want to go farther.
I couldn't figure out the whole load file thing with my tools when I started, so I ended up writing my own load file -- that's probably stupid, I'd love to see how it "should" be done.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Many thanks for your reply, its greatly appreciated as I feel a little stuck.
I have already checked the beginning of Flash memory located at
0x08000000 in debug. The very first entry is the stack which is as expected 0x20020000 and the next entry is at the reset_handler location which is the first line of code in startup_stm32f2xx.s This is entirely consistent with the DMP file.
Check memory at 0x00000000 -- that's what gets executed. ST maps the flash to 0x08000000 all the time, but other things can map to 0x00000000 (and no, I don't recall what they are or how to get them there -- I just remember that you can make it happen).
If your setup is mapping something else into that spot, then it doesn't matter what's in flash.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com
As expected data at 0x00000000 and 0x08000000 are identical.
A scope on the Reset pin suggests that OpenOCD / drivers aren't pulling the pin low. I'm not sure if this is important or if OpenOCD can perform the same function through JTAG.
How is your interrupt vector table defined? Are you sure its booting from flash and not sram? check your linker script
My stm32f103 board has jumpers to boot off SRAM, Flash and Embedded Mem. I leave it jumpered to boot off SRAM since that allows me to load and debug from memory under gdb most effectively - at this stage in the development anyway
Everything apart from .data .bss and .user_heap is assigned to RAM located at 0x20000000 .isr_vector is the first to go into Flash.
I'm not sure how to work out from the linker script how it is booting?
I thought booting is defined by BOOT1 which is pulled low by 10k and only connected to an unpopulated jumper.
The device I have doesn't have an external bus.
The issue seems to be OpenOCD 0.7.0 ! I installed OpenOCD 0.6.1 and all is well - crazy!!
I guess running Windows 7 - 64 bit and 64 bit versions of OpenOCD might have something to do with it?
Check if the adapter configuration has changed between versions.
-a
I'm not sure how I would check that. I use the driver that shipped with both OpenOCD v0.6.1 and v0.7.0.
The cfg files are also the same. The only difference is that v0.7.0 said in 2 places that cortex_m3 was deprecated to cortex_m.
All I did was point eclipse to the v0.6.1 version of OpenOCD!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.