Different jump address for STM32F429?

[bobdeschambault9]

Posted on March 10, 2015 at 18:19

Hi,

I have a legacy boot loader that was developed on an STM32F407.  There is a line of code that computes the JumpAddress before it jumps to the main application.  The line is:

    JumpAddress = *(__IO uint32_t *)(vectorAddress + 4);

I am running the code on an STM32F429, but the boot loader project is set to a 407.  My main application is running at 0x8020000.  When I compile the code for a 407, the jump is calculated correctly (0x8020559), but when I compile the main application code to use a 429, the jump address is totally out to lunch, something like 0xF6Cxxxxxx.  How would the boot loader know that the main application has been compiled for a 429?  My best guess is that I should be compiling my boot loader to use a 429.  Any words of wisdom?Thanks,Bob

[Tesla DeLorean]

Posted on March 10, 2015 at 19:26

It doesn't, check how you've configured your tools/project, and what the .MAP file tells you about the code you've generated.

I've got code for an F205 that would run fine on an F429

[bobdeschambault9]

Posted on March 10, 2015 at 21:20

Thanks I will check that.  Is it possible the JTAG debugger I am using might be getting confused?  I am using a JLINK and I was wondering if there might be problems when mixing code from two different chips in my two projects.  I am using the MDK and I have created a workspace that comprises the boot loader and main app projects.  If the two projects use different target configurations, could that affect how the debugger works?

[Tesla DeLorean]

Posted on March 10, 2015 at 23:41

I wouldn't portray them as that different. The first 1MB of FLASH writes in exactly the same way, and the PLL/clock settings to run at 168 MHz are also the same.

You'd want to review what the start up code in the application does, and you should also be able to trace/step through the transition from the boot loader to the application. If it's loading, and jumping to the wrong address, it's because the table you have provided is wrong. You need to reexamine the table, at 0x08020000 where you've situated it, and confirm it has valid vectors in it. You need to examine your startup code, and what SystemInit() in system_stm32f4xx.c does, and the address it programs into the Vector Table Offset Register (SCB->VTOR). On the application side you could also not ''run to main'', and breakpoint the ResetHandler entry point. While it's convenient to point at the chip or the debugger, the cause is likely far more mundane.