Support vector table relocation?

[ah-]

Hi Jorge and friends,

For various reasons I'm trying to use cortex-m-rt on a stm32l151 with a bootloader at 0x0800_0000.
This means my memory.x looks like this:

MEMORY
{
  FLASH : ORIGIN = 0x08004000, LENGTH = 48K
  RAM : ORIGIN = 0x20000000, LENGTH = 16K
}

so my user code plus the vector table starts at 0x0800_4000.
On startup the bootloader runs first, and once it's done it jumps to the reset handler at *0x0800_4004.
So far this works, and my main (well actually RTFMs init and idle) runs as expected.
However, none of the interrupts work, as the stm32 still uses the bootloader vector table at 0x0800_0000.

To fix that I'm currently running unsafe { p.core.SCB.vtor.write(0x4000) }; in init, after which everything runs just fine again.

Would it make sense to handle this vector table relocation in cortex-m-rt or should we consider this a bug of the bootloader?

If we want to fix it in cortex-m-rt, how could the fix look like? We'd need to write the relative offset from start of flash to where the vector table ends up, but as far as I can tell we don't know anymore that the original start of FLASH was at 0x8000_0000.

[adamgreig]

should we consider this a bug of the bootloader?

I would say yes; bootloaders should either set VTOR or copy the application vector table to RAM and remap it appropriately (e.g. on thumbv6 without VTOR), before jumping to application code. See for example this article from ARM/Keil. The bootloader has all the information it needs to do this properly, while cortex-m-rt doesn't in general.

[jonas-schievink]

Can this be closed, or is there a use case where cortex-m-rt needs to be involved?

[adamgreig]

I vote for closing; this is definitely behaviour the bootloader itself should take care of, and if it doesn't, chip/board support code can also take care of it. Doesn't need any special help from cortex-m-rt AFAIK.

[jonas-schievink]

Okay, closing then. If some use case comes up we can always reopen.