Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
STM32F3: Remove dependence upon a specific flash vector table location #4324
The STM32F3 cmsis_nvic code is currently checking for a specific flash address when determining if the vector table is in flash or RAM. By changing the test to instead see if the vector table base is NOT set to
Steps to test or reproduce
Create an STM32F3 based project but with the flash vector table moved to a different location (requires modifying the VECT_TAB_OFFSET setting in your target's system_stm32f3xx.cpp file, and moving the KEEP(*(.isr_vector)) line from your target's ld file (e.g. STM32F303XC.ld) to a different location ; be sure to align it to a multiple of 0x200). Without the changes from this commit, any attempt to set an interrupt handler will fail because the cmsis_nvic code will think the ISR vectors are already in RAM, since they are not at the expected flash address. With the changes, setting interrupt handlers properly results in the copy of the flash ISR vectors into RAM before modification.
@theotherjimmy I'm doing a project using a target based on the STM32F303xC. My project requires a custom boot loader, that I have occupying the first 8KB of the flash, so I modified my target's STM32F303XC.ld linker file to move the mbed image by changing the FLASH line as follows:
I also modified my target's system_stm32f3xx.cpp file to change the vector table offset to:
I have a real, custom boot loader that does DFU that gets programmed into the flash starting at 0x08000000, but for the purposes of testing this change, it would be sufficient to create a dummy boot loader that does nothing other than jump to the reset vector at the new 0x08002004 vector table address.
If you would find it useful, I could create an mbed-os patch file to modify the DISCO_F303VC target to move the vector table somewhere other than 0x08000000, and a simple main.cpp file that registers an interrupt handler for the user button on that board, and add them as attachments here, but this code should not be checked in.
@theotherjimmy @bridadan Here is a zip with a sample mbed-os project based off my mbed-os repository fork, that adds a dummy boot loader to shift the vector table 8KB up from the base of flash on a DISCO_F303VC board using the GCC_ARM toolchain.
Unzip the zip file somewhere, then cd into STM32F303xC-VectorTest, run "mbed deploy", "cd mbed-os", "git apply ../mbed-os-DISCO_F303VC-dummy-bootloader.patch", "cd ..", "mbed compile", then load the BUILD/DISCO_F303VC/GCC_ARM/STM32F303xC-VectorTest.bin output file into an STM32F3 Discovery board and you should be able to toggle the LD4 LED by pressing the USER button (using an interrupt).
This same test will fail to work if you start from an mbed-os branch that doesn't include the changes from this pull request, because the flash vector table will not get copied into SRAM, as it should.
Because the location of the vector table, and the code in this pull request are target specific, I'm not sure that it would make much sense to try to create a generalized test for the mbed-OS test suite, but I leave that up to the experts. :)
I just want to minimize the number of files that I need to keep forked for my own target, and the removal of the STM32F3 hard-coded flash vector table addresses done in this pull request would be useful to anyone else who similarly wanted to use a custom boot loader with mbed-os on an STM32F3 based target.