2014-12-01 12:36 PM
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-table2014-12-01 04:05 PM
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.2014-12-02 12:54 AM
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=false2014-12-02 12:58 AM
Clive1, you say:
>The boot loader, and the first code executing, still needs to reside at 0x08000000Does 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.2014-12-02 03:41 AM
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?2014-12-04 06:37 AM
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 crashright 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 080126D1As 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.2014-12-10 05:23 AM
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!