0
votes

I am trying to understand the placement of the vector table for Cortex-M3 processor.

According to the Cortex-M3 arch ref manual, the reset behavior is like this (some parts are omitted):

enter image description here

So, we can see that the vectortable comes from the VTOR (Vector Table Offset Register).

According to the Cortex-M3 tech ref manual, the VTOR is defined as:

enter image description here

So we can see, it has a reset value of 0x0. So based on the above 2 criteria, the Cortex-M3 processor expects a vector table at the absolute address 0x0 in the Code area after reset.

But in my MDK uVision IDE, I see my application is placed in the IROM1 area, which starts at 0x8000000, which is within the 0.5G Code memory area according to the Cortex-M3 memory map.

enter image description here

And since it has the Starup button checked, I guess that means the IROM1 area should contain the vector table (please correct me if I am wrong about this).

So I think the vector table should lie at the beginning of IROM1 area, i.e. 0x8000000. And it is indeed so. Below pic shows that at the beginning of IROM1, it is the vector table's 1st entry, the SP value.

enter image description here

And what's more strange, the VTOR register (at 0xE000ED08) still holds a 0x0 value:

enter image description here

So, how could my vector table be found with a 0x0 VTOR reset value?

And just out of curiosity, I checked the memory content at 0x0, there contains exactly the same vector table content as IROM1. So who did this magic copy??

enter image description here

ADD 1 - 4:39 PM 10/9/2020

I guess there must be something I don't know about the startup check box in below pic.

enter image description here

ADD 2 - 5:09 PM 10/9/2020

Thanks to @RealtimeRik and @domen. I downloaded the datasheet for STM32F103x8_xB(https://www.st.com/resource/en/datasheet/stm32f103c8.pdf). In section 4 Memory mapping, I saw below diagram:

enter image description here

So it seems the [0x0, 0x8000000) range does get aliased to somewhere else. But I haven't found how to determine where it is aliased to...

ADD 3 - 5:39 PM 10/9/2020

Now I found it!

I downloaded the STM32Fxxx fef manual (btw it's really huge).

In section 3.4 Boot configuration, it specifies the boot mode configured through the BOOT[1:0] pins.

enter image description here

And with different boot mode, different address aliasing is used:

Depending on the selected boot mode, main Flash memory, system memory or SRAM is accessible as follows:

  • Boot from main Flash memory: the main Flash memory is aliased in the boot memory space (0x0000 0000), but still accessible from its original memory space (0x800 0000). In other words, the Flash memory contents can be accessed starting from address 0x0000 0000 or 0x800 0000.
  • Boot from system memory: the system memory is aliased in the boot memory space (0x0000 0000), but still accessible from its original memory space (0x1FFF B000 in connectivity line devices, 0x1FFF F000 in other devices).
  • Boot from the embedded SRAM: SRAM is accessible only at address 0x2000 0000.

What I saw is Boot from main Flash memory.

Well finally I can explain why 0x800 0000 is chosen...

ADD 4 - 3:19 PM 10/15/2020

The placement/expectation of the interrupt vector table at the address 0 is similar to the IA32 processor in real mode...

1
this is all documented you should always have the proper documentation handy before starting this work. as you eventually found address zero is mapped to one of a few places depending on strap pins or nonvolatile bits that determine the mapping at zero, ideally you want to use the real flash address in the vector table not zero based...each chip vendor is different if they map at all and if so where, even within the stm32 family there is more than one ideal address to place the vector table.old_timer

1 Answers

3
votes

There is no "Magic Copy". 0x00000000 is aliased to 0x08000000.

The actual memory is physically located at 0x08000000 but can also be access at 0x00000000.

If you look in the processor specific reference manual you should find this in the the memory map section.