1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Stack after reset for STM32F with gdb

Discussion in 'Embedded' started by Fredxx, Sep 2, 2013.

  1. Fredxx

    Fredxx Guest

    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?
     
    Fredxx, Sep 2, 2013
    #1
    1. Advertisements

  2. Fredxx

    Tim Wescott Guest

    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, Sep 3, 2013
    #2
    1. Advertisements

  3. Fredxx

    Fredxx Guest

    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.
     
    Fredxx, Sep 3, 2013
    #3
  4. Fredxx

    Tim Wescott Guest

    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, Sep 4, 2013
    #4
  5. Fredxx

    Fredxx Guest

    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.
     
    Fredxx, Sep 4, 2013
    #5
  6. Fredxx

    rombios Guest

    Its not clear how I can setup the Debug Configuration in order to ensure
    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
     
    rombios, Sep 4, 2013
    #6
  7. Fredxx

    Fredxx Guest

    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.
     
    Fredxx, Sep 4, 2013
    #7
  8. Fredxx

    Fredxx Guest

    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?
     
    Fredxx, Sep 4, 2013
    #8
  9. Check if the adapter configuration has changed between versions.

    -a
     
    Anders.Montonen, Sep 5, 2013
    #9
  10. Fredxx

    Fredxx Guest

    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!
     
    Fredxx, Sep 5, 2013
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.