2025-11-11 2:20 PM
The linkerscripts generated by the STM32CubeMX for STM32F767ZI appear to use the AXIM interface:
/* Specify the memory areas */
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 2048K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 512K
}But the default boot vector is set to address 0x0020 0000 which is a ITCM address:
# gdb console
> monitor stm32f7x options_read 0
stm32f2x user_options 0xFFC, boot_add0 0x0080, boot_add1 0x0040boot_add0 0x0080 indicates ITCM.
When I move the boot vector by 128K, I have to set boot_add0 to 0x0088 (8*16K=128K) and set FLASH ORIGIN in above linker script to 0x08020000. Otherwise it will not work. That is a bit confusing.
Thanks.
2025-11-11 3:16 PM - edited 2025-11-11 3:24 PM
This works because the vectors are read as data. Assume your vectors table is located at 0x08000000 in the linker script, which is aliased to 0x00200000 (via TCM). Your reset address (via AXIM) at 0x08000004 is 0x08001235.
When the MCU starts, it reads the start address from 0x00200004 and the value is 0x08001235. Then the program just runs using the AXIM addresses. Position-independent code is not needed.
The difference between TCM and AXIM access is illustrated on figure 3 in RM0410. The TCM path goes thru the ST proprietary ART instruction cache, while AXIM path bypasses ART. If you want instruction caching with AXIM, use the standard instruction cache of Cortex-M7.
2025-11-12 12:20 AM
Thanks. Indeed. When I set boot_add0 to 0x2000, then my program starts as well. So I was running via AXIM all the time. Now I wonder why STM uses AXIM in its generated linker scripts and never ITCM? The latter is desribed as faster and less complex than AXIM and instruction cache.