Using MX to locate IVT in RAM

[RBack.1]

I am using the STM32F746VET6 which was setup with STM32CubeMX project. In the code it creates I see there's a STM32F746VETX_RAM.ld linker file and a #define VECT_TAB_SRAM to locate the IVT in RAM, but I don't see in MX where I specify that I want the autogenerated code to behave that way. Am I just missing something?

The reason I want the IVT in RAM is that I want to reconfigure which ISR is used for a timer depending upon a setting set through the SPI port. Doing this by overwriting an IVT in Flash would be a problem for my bootloader which has a CRC over the entire Flash range.

[RBack.1]

Thanks, I did end up declaring a section in the linker file. I do have to make sure the section defined there is large enough for the size of the objects in the c file but it's working enough for me to keep moving on without trying to make it perfect.

[Tesla DeLorean]

>>what's telling the linker not to place other variables..

In this case nothing, I was trying to establish that the mechanics worked, so we could focus on where the issue in the implementation was.

In a first-principles sense the MCU works as designed. The issue then falls to whether your addresses point to the right locations, and that what you're copying contains the correct information.

If you have a terminal and printf() working a "%p" will print a pointer's address

[RBack.1]

I see. Well, the project is functioning and I have something that is somewhat maintainable. I would have preferred to have first used features inherent in MX and the auto-generated code if they were available since it's already used for everything else in this project and I wouldn't want to confuse any other engineers in my company that reuse this code. It seems making use of ST's USER_VECT_TAB_ADDRESS, VECT_TAB_SRAM, and VECT_TAB_OFFSET definitions cause VTOR to get set before my code has a chance to copy the IVT to RAM, however.