Bootloader - jump to APPLICATION_ADDRESS

[paul2]

Posted on October 30, 2015 at 14:22

Hi,

I'm having some issue loading my application from the APPLICATION_ADDRESS -Using a STM32F4 Discovery board -As bootloader application I'm using the STM32F4 example

http://www.st.com/web/en/catalog/tools/PF257904

-I'm using the bootloader firmware with default APPLICATION_ADDRESS

#define APPLICATION_ADDRESS (uint32_t)0x08008000

-When I'm loading the STSW-STM32068 .bin example on my USB-stick, the demo gets loaded and runs like it should. so far so good.. -Next step is to create a bin file of my own application. -I used the following settings for my application:

mem.ld file (.map file is updated accordingly):
FLASH (rx) : ORIGIN = 0x08008000, LENGTH = 1024K
system_stm32f4xx.c file:
#define VECT_TAB_OFFSET 0x8000 /*!< Vector Table base offset field.

-Building the .bin file and rename it ''image.bin'' as needed by the bootloader firmware -According to the LED's the .bin is loaded to the Flash memory correctly. Also checked with a debugger (memory is filled from 0x08008000). -When I press the USER button the bootloader starts all over again, loading the .bin file from the USB-stick. I would expect that it will jump the loaded application @ 0x08008000 Do I miss something? Why is the bootloader not jumping to the APPLICATION_ADDRESS?

[Tesla DeLorean]

Posted on November 10, 2015 at 22:18

The thing is, I'm a savant, not a psychic, so I'm not going to try an imagine what you've created. If you want to show me what you've created it would be helpful in diagnosing the problem, rather than keep telling me symptoms for something I can't touch or see.

Does the failure correlate with the size of the buffer you've allocated for your output device? Is it using a USART or SWV for output? Is the output from the buffer dependent on an IRQ firing? Is it firing? You said ''

the application doesn't stop and works like it should

'', I don't know what that means, you suggested RAM, I countered with clocks and stuff. Are you calling the other code in an IRQ Handler?

[paul2]

Posted on November 11, 2015 at 09:37

Hi,

Issue is solved. The debugger showed me the information below: Thread [1] <main> (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)         0x80001b6         <signal handler called>() at 0xfffffff9      

After all the issue wasn’t related to debugging, UART communication or whatsoever.

The issue was caused by setting the “#define VECT_TAB_OFFSET�? to a wrong offset.

Issue solved be using #define VECT_TAB_OFFSET 0x8000

Thanks.