STM32F10x bootloading and different jump addresses

[bjer]

Posted on March 04, 2011 at 16:26

STM32F10x bootloading and different jump addresses

[Tesla DeLorean]

Posted on May 17, 2011 at 14:26

You'd use NVIC_SetVectorTable() to point to the alternate vector table addresses, and you could do so in a way that would automatically use the address for which the code has been compiled to run. Use a symbol (__Vectors) for the table.

The boot loader could pick an application to run based on a magic number stored in RAM.

[bjer]

Posted on May 17, 2011 at 14:26

Hi and thanks for the reply, Im not sure I understand what you mean though.. Running the application from RAM is not an option for me because it wont fit in the internal RAM which is the only RAM I have available.

My current bootloader implementation uses the NVIC_SetVectorTable() function before jumping to the desired applications reset vector. This works well but it only works if I put the application in an specific address on the program flash. This is because the vector table doesnt contain relative offsets but the actual address of the IRQ handlers. Im assuming this is how it works on the ARM (Im quite an ARM newbie), the addresses in the vector table are absolute? What im trying to achieve is to have realtive vector table addresses so I can put a binary on any location in the flash and run it from there with IRQs. Is this even possible? Are there any better ways of doing this?

Can I offset the program counter/pointer so that it thinks its at program flash address 0 when its actually somewhere else?

BR,

Björn

[Tesla DeLorean]

Posted on May 17, 2011 at 14:26

I didn't mention running the application in RAM, I said to store a magic value in RAM, so the FLASH based bootloader could make a choice about where to jump to when it starts/restarts.

ie if (*(unsigned long)0x2000FFF0) == 0xDEADBEEF)) execbase = 0x08002000; So that say it normally executes the application at 0x08001000, but that application decides it needs to run APP2 @ 0x08002000, then it sets the RAM variable and reboots the loader. The application should set it's own NVIC_SetVectorTable(). You could also assign one flash block to contain information about which application to execute, or where they are located. You could also structure the applications in a way that the boot loader could enumerate them. You could make sure the compiler/linker build the code in a location insensitive fashion. You could have your boot loader copy/relocate the vectors into RAM. ROM based applications aren't well suited to relocation. So instead of generating HEX files *before* you know what address you want to run them at, you might consider using ELF/AXF files containing relocation data and have your download program/loader fix them up at the point you know what memory address you want them to go. You can use PC relative addressing, you can compute the addresses of you IRQ routines and build an NVIC vector table on the fly. I think you'd better learn the ARM platform a little better before you start on more complicated schemes.

[bjer]

Posted on May 17, 2011 at 14:26

Thanks again for your answer :-). I do wish I had more time to learn the ARM platform but such is the life of an consultant, you are supposed to be an expert from day one..

I think I will go with loading the applications vector table to ram in the boot loader and then change them to match the offset of my application before jumping, this should work right?

BR,

Björn