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?
Stack after reset for STM32F with gdb
Started by ●September 2, 2013
Reply by ●September 3, 20132013-09-03
On Mon, 02 Sep 2013 21:34:28 +0100, Fredxx wrote:> 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
Reply by ●September 3, 20132013-09-03
On 03/09/2013 18:55, Tim Wescott wrote:> On Mon, 02 Sep 2013 21:34:28 +0100, Fredxx wrote: > >> 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.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.
Reply by ●September 4, 20132013-09-04
On Tue, 03 Sep 2013 22:08:38 +0100, Fredxx wrote:> On 03/09/2013 18:55, Tim Wescott wrote: >> On Mon, 02 Sep 2013 21:34:28 +0100, Fredxx wrote: >> >>> 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. > > 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
Reply by ●September 4, 20132013-09-04
On 04/09/2013 18:32, Tim Wescott wrote:> On Tue, 03 Sep 2013 22:08:38 +0100, Fredxx wrote: > >> On 03/09/2013 18:55, Tim Wescott wrote: >>> On Mon, 02 Sep 2013 21:34:28 +0100, Fredxx wrote: >>> >>>> 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. >> >> 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).As expected data at 0x00000000 and 0x08000000 are identical.> If your setup is mapping something else into that spot, then it > doesn't matter what's in flash.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.
Reply by ●September 4, 20132013-09-04
> 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 = 0x00000000How 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
Reply by ●September 4, 20132013-09-04
On 04/09/2013 21:08, rombios wrote:>> 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 > > How is your interrupt vector table defined? > Are you sure its booting from flash and not sram? check your linker scriptEverything 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.> 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 > anywayThe device I have doesn't have an external bus.
Reply by ●September 4, 20132013-09-04
On 02/09/2013 21:34, Fredxx wrote:> 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? >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?
Reply by ●September 5, 20132013-09-05
Fredxx <fredxx@nospam.com> wrote:> The issue seems to be OpenOCD 0.7.0 ! I installed OpenOCD 0.6.1 and all > is well - crazy!!Check if the adapter configuration has changed between versions. -a
Reply by ●September 5, 20132013-09-05
On 05/09/2013 16:00, Anders.Montonen@kapsi.spam.stop.fi.invalid wrote:> Fredxx <fredxx@nospam.com> wrote: >> The issue seems to be OpenOCD 0.7.0 ! I installed OpenOCD 0.6.1 >> and all is well - crazy!! > > Check if the adapter configuration has changed between versions. >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!
