FreeRTOS crashing when relocated from 0x8000000

Kernel
1

dibosco wrote on Tuesday, July 08, 2014:

Folks,

This is far from the first time I’ve done an STM32 bootloader, but I’m having funky things going on with one for the STM32F107VC.

All compiles and runs fine when running from 0x8000000, but as soon as I relocate the code to 0x8003000 it falls over. To explain what I’ve done:

I’m using Rowley Crossworks and you can move the program around flash very easily by using this Section Placement Macro:

FLASH_START=0x08008000

I’ve done it many times in different projects. I can recompile with different flash start addresses and the debugger happily shows you it running from wherever you’ve located it. Both with run-to-complete and FreeRTOS projects this has been fine.

However, when running the STM32F107VC demo that I have modified, it will not work. If I program the device from the debugger or if I run the bootloader and have the bootloader load the new image in at the relocated start point.

I’m getting to here:

static void prvPortStartFirstTask( void )

Whic is assembler:

ldr r0, 0x0800A064 <prvPortStartFirstTask+0x18> [r0 contains 0xe000ed08, location 0xe000ed08 contains 0]
ldr r0, [r0] [Now r0 contains 0, location 0 contains 0xFFFFFFFF]
ldr r0, [r0] [Now r0 conatains 0xFFFFFFFF]
msr msp, r0 [MSP contains 0xfffffffc (!)]
cpsie i
dsb sy
isb
svc #0

After the svc instruction the program leaps off to 0xfffffffe

I am assuming this is why it’s not running.

If I run the bootloader itself (a stripped down FreeRTOS), when I get to the part that jumps to the application:

void JumpToNormalApplication(void)
{

volatile unsigned long JumpAddress;

SysTick_CounterCmd(SysTick_Counter_Disable);
SCB_VTOR = (unsigned long)0x8008000;
JumpAddress = *(volatile unsigned long*) (0x8008000 + 4);
Jump_To_Application = (pFunction) JumpAddress;
Jump_To_Application();

}

The Jump_To_Application assembly is as follows:

ldr r3, 0x08006AC8 <JumpToNormalApplication+0x3C> [0x08006AC8 contains 0x200079a4]
ldr r3, [r3] [0x200079a4 contains 0x0800828d]
blx r3 [ And so it jumps to 0x0800828d, which is now where it should go!]

So, is this enough information to poke me in the right direction or be able to tell what on earth is going on/wrong?

Many thanks!

2

rtel wrote on Tuesday, July 08, 2014:

The following code resets the system stack pointer back to the start of the system stack (the stack used by main). The system stack is then used by interrupts. It finds the location of the system stack by first locating the vector table, then reading the stack top value from the first position in the vector table (this is how the Cortex-M3 locates the stack when you power it on). So:

ldr r0, 0x0800A064 <prvPortStartFirstTask+0x18> [r0 contains 0xe000ed08, location 0xe000ed08 contains 0]

This is loading the address of the NVIC offset register, which is 0xE000ED08, into r0.

ldr r0, [r0] [Now r0 contains 0, location 0 contains 0xFFFFFFFF]

This is loading the value from the NVIC offset register to find the address of the vector table. By default the vector table will be (at least aliased) to address 0. That is where you would expect to find it if you have not remapped anything, because again this is where the Cortex-M3 itself expects it to be when it is power on. The 0 is presumably correct, bu the value at 0 is wrong (unless you have RAM at address 0xffffffff).

ldr r0, [r0] [Now r0 conatains 0xFFFFFFFF]

This is loading the address of the stack top from the the first position in the vector table.

msr msp, r0 [MSP contains 0xfffffffc (!)]

This is loading the stack address into the stack pointer. You have lost the least significant bits of the address as the stack cannot be on an odd boundary (like ffffffff).

So, the error seems to be the address of the stack is not in whichever vector table is currently mapped to address 0.

Regards,
Richard Barry.

3

dibosco wrote on Tuesday, July 08, 2014:

Ah, thanks, what I was forgetting is that 0xE000ED08 is the VTOR register. This has zero in it, even if I come ouf ot the bootloader which has just put 0x08008000 into it, before it jumps to the application. Something in the prvSetupHardware() function is resetting it from 0x08008000 back to zero. I bet that will fix it. Will report back later. Thanks!

4

dibosco wrote on Tuesday, July 08, 2014:

It was this line:

NVIC_SetVectorTable( NVIC_VectTab_FLASH, 0x0 );

So, that was resetting the VTOR register. Not really sure why that line needs to be in there at all. Cost me a lot of time that one little line!