Startup Files with different chipsets

[bobdeschambault9]

Posted on April 20, 2015 at 23:28

Hi all,

I have a legacy boot loader that was run on an STM32F407.  It was located at 0x08000000 and my main application is located at 0x08020000.  I have seen a strange behaviour when I compile my main application code for an STM32F429.  If I use a main application with a normal 429 .s startup file, the boot loader doesn't appear to be able to jump to the main app.  If I use a 407 .s startup file with my main app but leave it configured as a 429, the boot loader jumps properly.  I checked the jump address and it is some nonsense value when I use the 429 startup file in the main app.  Can anyone help me understand what might be going on here?Thanks,Bob #indirect-data-pointer

[Tesla DeLorean]

Posted on April 21, 2015 at 01:05

Well you'd want to look at the differences in the vectors, the output from the linker (.MAP) and understand what the control transfer routine looks like.

If you're not calling the ResetHandler of the application image, then you'll need to review what is being called.

[bobdeschambault9]

Posted on May 08, 2015 at 20:50

Hi,

It turned out we were doing something very bad.  We have a fixed block at the beginning of our main application that contains dates, times, and revision information.  The fixed block was being placed in a fixed location that was based on the length of vector table.  Our old code was using a 407 and the vector table had an offset of 0x188 to the code.  The 429 chip has an offset of 0x1AC.  Unfortunately we did not change the location of this fixed block for the 429, so we were overwriting the vector table and had our application start address pointing to the wrong place.  Don't know if there is a constant defined somewhere that gives the length of the vector table for a given chip instead of us defining our own offset.

[pacman]

Posted on May 10, 2015 at 14:11

I'd like to propose a way to do this.

Place the fixed block with your information in the .rodata section (which hopefully goes into Flash memory)Right before your Reset_Handler, make a 32-bit pointer to the fixed block.Thus you can find the fixed block by reading address 0x00000004, then subtract 4 from ths, read the contents of this address and you have the pointer to the fixed block.