Bootloader Problem

[andrewkelly9]

Posted on February 12, 2010 at 17:23

Bootloader Problem

#bootloader

[Tesla DeLorean]

Posted on May 17, 2011 at 13:40

Check the MAP/HEX files to confirm the base address of the application code.

It is important that the low order address bit of any code you jump to is 1, the STM32 can only execute THUMB code. I export the address of the vectors in the application start up code, then use that to set the address. So provided you don't violate any alignment rules, the application is agnostic to the location it is loaded. In the startup.s file                EXPORT  __Vectors In the application.c file extern void * __Vectors; NVIC_SetVectorTable((u32)(&__Vectors), 0x0); // Smart Base Location Some assembler to enter the system boot loader looks like this, change the address to reflect the base address of you application. Reboot_Loader    PROC                 EXPORT    Reboot_Loader                 LDR        R0, =0x1FFFF000                 LDR        SP,[R0, #0]                 LDR        R0,[R0, #4]                 BX        R0                 ENDP -Clive

[andrewkelly9]

Posted on May 17, 2011 at 13:40

Could the odd boundary be my problem. I am locating code at 0x8004000 and attempting to run it.(on Even boundary). Don't know anything about thumb alignment. It is the entire binary that I am copying to this location.

My Code code was: void app_start(void) {     void (*app)();     irq_disable();     runapp=(void(*)())(0x8004000);     app(); } Replaced with the code you gave and still the same. I think IRQs are a distraction, it should still start? .arm .text global       start_application start_application:                 ldr        R0, =0x1FFFF000                 ldr        SP,[R0, #0]                 ldr        R0,[R0, #4]                 BX        R0 Thanks

[Tesla DeLorean]

Posted on May 17, 2011 at 13:40

The code assumes you have the Stack Pointer and Start Address as the first two words of the image.

If the first half-word is an instruction, you would need to jump to 0x8004001, as you are running Thumb code, not ARM code. -Clive

[andrewkelly9]

Posted on May 17, 2011 at 13:40

Sorry that address was

start_app:                 ldr        R0, =0x8004000                 ldr        SP,[R0, #0]                 ldr        R0,[R0, #4]                 BX        R0

[andrewkelly9]

Posted on May 17, 2011 at 13:40

No Luck. The start of Rom where it is jumping to starts with the IRQ table

so I presume that can start at location:0x8004000 I have no memory protection stuff turned on. Does anyone know of any sample code that jumps to another location in Rom? (written in C):__attribute__ ((section(''.isr_vector''))) void (* const g_pfnVectors[])(void) = {     (void (*)(void))((unsigned long)stack + sizeof(stack)),                                             // The initial stack pointer     ResetISR,                               // The reset handler     NmiSR,                                  // The NMI handler     FaultISR,                               // The hard fault handler etc.

[Tesla DeLorean]

Posted on May 17, 2011 at 13:40

You're going to need to examine the code/data generated by the compiler/linker. Unless the correct addresses and linkage is occurring this isn't going to work.

Try using a

JTAG

debugger and single stepping the critical code to ensure it is doing what you expect. -Clive

[andrewkelly9]

Posted on May 17, 2011 at 13:40

I have looked at AN2557 and there doesn't appear to be much in it.

I am using GCC, so the function NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x4000); doesn't appear to be available to me. Looking at the map file though, the vectors are located at 0x8004000 The definition is as follows: __attribute__ ((section(''.isr_vector''))) void (* const gpVectors[])(void) = {     (void (*)(void))((unsigned long)stack + sizeof(stack)), and mapfile gives : .isr_vector    0x08004000      0x130 bin/startup.o                 0x08004000                gpVectors    So happy there.  I thought that maybe it was an alignment issue.  I copy the binary to 0x8004000  but maybe I should be runninfg the application from  0x8004001  (Bt the way, application runs fine without bootloader) My code to run application is: #define APP_ORIGIN 0x8004000 void app_start(void) {     void (*runapp)();     irq_disable();     runapp=(void(*)())APP_ORIGIN;     runapp(); } have also tried runapp=(void(*)())(APP_ORIGIN+1);

[andrewkelly9]

Posted on May 17, 2011 at 13:40

I will study the sample app, this is useful.

I notice they run app_address+4 when running the application, tried it quickly, bur I still crash. I will left you know if I get success from the app note. Thanks

[Tesla DeLorean]

Posted on May 17, 2011 at 13:40

Ok, you don't need to change the load location to 0x8004001, the low order bit simply flags to the program counter that the code in question is THUMB code. All code on the STM32 (Cortex-M3) must be THUMB, it cannot execute 32-bit ARM code.

Also remember that the first vector entry is the address of the stack top in RAM, the second entry is the reset vector. It is the address of the reset vector, not executable code. The assembler code to execute from a vector table would be                 LDR        R0, =0x08004000                 LDR        SP,[R0, #0]                 LDR        R0,[R0, #4]                 BX        R0 If NVIC_SetVectorTable() is not available you will need to reprogram the NVIC directly to point the hardware to the vector table. -Clive