Skip to main content
gabriele
gabriele
Associate
December 1, 2014
Question

Relocate app in STM32F105

  • December 1, 2014
  • 6 replies
  • 1250 views
Posted on December 01, 2014 at 21:36

Hi!

On a board with a STM32F105 uC I am implementing a uSD bootloader. First of all I wanted to relocate the application to a different address in flash, but I'm getting a stack pointer error.

Here the 2 changes:

Linker file:  

FLASH (rx)      : ORIGIN = 0x0800C000, LENGTH = 128K - 0xC000

File system_stm32f10x.c:

&sharpdefine VECT_TAB_OFFSET  0xC000

Right after start (even before getting to the main() function) the application crashes due to a stack pointer problem, in fact the sp register points to 0xFFFFFFFF instead of 0x20010000.

However, the .map seems correct... 

                0x20010000                __stack = (ORIGIN (RAM) + 0x10000)

                0x20010000                _estack = __stack

                0x00000400                __Main_Stack_Size = 0x400

...

.isr_vector     0x0800c000      0x1e4

                0x0800c000                . = ALIGN (0x4)

If I change the sp register manually (debug) at the beginning, the application starts correctly.

Does anyone have an idea why I'm getting this error?

Many thanks for your help!

Caleg

#stm32-relocate-sp-vector-table
    This topic has been closed for replies.

    6 replies

    Tesla DeLorean
    Tesla DeLorean
    Guru
    December 2, 2014
    Posted on December 02, 2014 at 01:05

    Ok, but what does the .HEX file look like?

    Setting the SP to 0xFFFFFFFF suggests it's loading a blank FLASH region. You can't change the boot address of the processor. The boot loader, and the first code executing, still needs to reside at 0x08000000. Look at how you are jumping to the application code.
    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    gabriele
    gabrieleAuthor
    Associate
    December 2, 2014
    Posted on December 02, 2014 at 09:54

    Attached the .hex file

    ________________

    Attachments :

    CanEncoder.hex : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I11r&d=%2Fa%2F0X0000000bh8%2F7h9ylAVNobP_1vRioeFFXqm34xyO2VlcH_VnVznm.Zg&asPdf=false
    gabriele
    gabrieleAuthor
    Associate
    December 2, 2014
    Posted on December 02, 2014 at 09:58

    Clive1, you say:

    >The boot loader, and the first code executing, still needs to reside at 0x08000000

    Does that mean that I cannot jump to a location such as 0x0800C000 without having my own bootloader at  0x08000000?

    My current application actually start with the Reset_Handler() from a location higher than 0x0800C000, but as soon as the SystemInit() is called the application crashes due to the wrong sp.

    Tesla DeLorean
    Tesla DeLorean
    Guru
    December 2, 2014
    Posted on December 02, 2014 at 12:41

    Your code can jump wherever it wants, but when the processor is resets it's going to pull it's first two vectors from the base of FLASH (or whatever ROM/RAM is mapped at ZERO by the BOOTx pins). So you're going to want some vectors/code there (0x08000000) for execution to start properly.

    Quick look at the vector table in the .HEX suggest it's linked properly for an 0x0800C000 base, with SP=0x20010000,PC=0x08012685

    Would suggest you review the IAP examples, and how they split the loader/app functions.

    I assume you see the crashing behaviour in the debugger? Which one? And if you do a memory view of 0x08000000 or 0x00000000 what do you see?
    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    gabriele
    gabrieleAuthor
    Associate
    December 4, 2014
    Posted on December 04, 2014 at 15:37

    Sorry for the late answer, I wasn't in my office.

    With my debugger (Mentor Sourcery, arm-2013.05-23-arm-none-eabi) I get the crash

    right after the SystemInit call (in file startupt_stm32f10x_cl.S)

    LoopFillZerobss:

      ldr   r3, = _ebss

      cmp   r2, r3

      bcc   FillZerobss

    /* Call the clock system intitialization function.*/

      bl  SystemInit  

    at this point the memory looks like this:

    0x08000000  FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

    ...

    0x0800C000  20010000 08012685 080126D1 080126D1

    As you suggested, for the next step I will develop the bootloader, place it at 0x8000000, load the relocated application via microSD and see if it works.

    Thanks again.

                                                                                                                    

    gabriele
    gabrieleAuthor
    Associate
    December 10, 2014
    Posted on December 10, 2014 at 14:23

    In fact now that I have a working bootloader the  stack pointer issue is solved and the application starts correctly at a different address.

    Many thanks for your support!

    Terms & ConditionsAccessibility statement