Understanding the Memory Map
The ARM Cortex-M architecture uses a unified memory space where code and data share the same address range. Unlike traditional Harvard architectures that separate instruction and data buses physically in terms of addressing, the Cortex-M presents a single linear address space to software. However, the hardware treats certain regions differently based on access type and address location.
In most Cortex-M implementations, including the M0+, the memory map is designed so that the lowest addresses (starting at 0x0000_0000) are typically mapped to Flash memory for booting. Conversely, the highest addresses are reserved for system control structures and peripheral registers. The specific addresses 0xFFFF_FFF0 through 0xFFFF_FFFF fall into this upper region. This design allows the processor to always know where to find the entry point for the program without needing external configuration during the reset sequence.
It is important to note that while the theoretical address space extends up to 4GB, actual physical implementation depends on the specific chip vendor. For example, an STM32L0 series might have less than 1MB of total memory, yet the CPU still expects vectors at the very end of the 32-bit address space. The hardware automatically maps these high addresses to the beginning of the Flash bank if the device supports remapping, or simply reads them directly if they reside in mapped memory.
The Reset Vector Table Structure
The vector table is an array of 32-bit words located at a specific base address. By default, this base is set to 0x0000_0000, but it can be relocated using the Vector Table Offset Register (VTOR). When the CPU resets, it does not look at 0x0000; instead, it looks at the absolute top of the address space to initialize the core state.
At offset 0x0000 (which corresponds to address 0xFFFF_FFFC in the top-mapped view), the CPU reads the Initial Stack Pointer (MSP) value. This value tells the processor where the top of the stack is located in RAM. Without a valid stack pointer, any function call or local variable allocation will result in a hard fault immediately upon startup.
At offset 0x0004 (address 0xFFFF_FFF8), there is usually the Exception Handlers start, which includes NMI, HardFault, and MemManage. Finally, at offset 0x0008 (address 0xFFFF_FFF0), the CPU reads the Reset Handler address. This is the first instruction the CPU executes after initialization. It typically points to the _start assembly routine, which sets up the BSS segment, copies data from Flash to RAM, and then calls main().
Why These Specific Addresses?
The use of the highest addresses simplifies the boot process. The reset logic inside the Cortex-M core is fixed. It does not need to check configuration pins or registers to determine where the vector table is for the initial boot. It simply fetches from the top. If the developer wants to run code from RAM instead of Flash, they must move the vector table to a lower address in RAM and update the VTOR register before enabling interrupts. Until that happens, the CPU continues to read vectors from the original Flash location at the top of the map.
Common Boot Issues
Developers often encounter issues when the vector table is corrupted or misaligned. A common symptom is a HardFault occurring immediately after reset. This usually happens because the Initial Stack Pointer value read from 0xFFFF_FFFC is invalid, pointing to unmapped memory or causing a stack overflow instantly.
Another frequent issue arises during debugging sessions where the debugger fails to halt at main(). This can occur if the Reset Handler at 0xFFFF_FFF0 contains garbage data due to incomplete flashing or bit-banding errors. Ensuring that the linker script correctly places the vector table at the start of the Flash section is essential. The linker script should define the RESET symbol to point to the correct offset within the flash region.
Additionally, some developers mistakenly assume that because the address is 0xFFFF_FFF0, it resides in SRAM. In many low-power devices, the upper addresses are mirrored or aliased to Flash. Accessing these addresses as if they were writable RAM will result in a bus fault. Always consult the specific datasheet for memory mapping details, as some vendors may implement partial memory maps where the top addresses are not fully accessible or behave differently.
Relocating the Vector Table
While the default behavior is robust, advanced applications may require relocating the vector table. This is necessary when running firmware from RAM for faster execution or when using multiple memory banks. To relocate the table, you must modify the linker script to place the vector array in the desired memory section, such as SRAM.
After placing the table in the new location, you must write the base address of this new table to the VTOR register. This register is part of the NVIC (Nested Vectored Interrupt Controller) in the Cortex-M core. Writing to VTOR informs the CPU of the new location for all subsequent exception handling. Note that this change only affects exceptions triggered after the write; the initial reset vectors are already fetched from the old location by the time VTOR is written.
Therefore, if you intend to boot from RAM, you must copy the entire vector table to RAM first, then update VTOR, and finally enable interrupts. Failure to follow this sequence can lead to unpredictable behavior where interrupts are handled by stale vectors in Flash while other operations expect vectors in RAM.
Frequently Asked Questions
Can I write to 0xFFFF_FFF0?
No, these addresses typically map to Flash memory where the vector table is stored. Attempting to write to them will likely result in a Bus Fault or HardFault, as Flash memory is generally read-only during normal operation unless specifically in programming mode.
What happens if the Stack Pointer at 0xFFFF_FFFC is zero?
If the Initial Stack Pointer is zero, the CPU will attempt to use address 0x0000 as the stack top. Depending on the memory map, this might overlap with the vector table itself or unmapped memory, leading to an immediate HardFault upon any stack operation.
Does every Cortex-M0+ chip have vectors at these exact addresses?
Yes, the ARM architecture specification mandates that the reset vectors are accessed at the top of the 32-bit address space. However, the physical memory mapped to those addresses varies by manufacturer, being either Flash, ROM, or mirrored regions.
How do I verify the content at these addresses?
You can use a debugger like GDB with OpenOCD to read memory directly. Use the command x/4wx 0xfffffff0 to dump the four words starting from the Reset Handler address, verifying that the values match your compiled binary's vector table.
Why is my debugger not hitting main()?
This often indicates that the Reset Handler address at 0xFFFF_FFF0 is incorrect or points to an invalid instruction. Check your linker map file to ensure the _reset_handler symbol is correctly placed and that the vector table in the hex file matches this expectation.