STM32F3: Remove dependence upon a specific flash vector table location

[bscott-zebra]

Description

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
the RAM address, it simplifies the code, and removes the dependency on the flash vectors being located at a specific address. This becomes important when adding a custom boot loader, which requires that the flash vector table location in the mbed project be at a different address.

Status

READY

Migrations

NO

Related PRs

None

Todos

None

Deploy notes

None

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]

@monkiineko could you share with us how you tested this?

[bscott-zebra]

@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:
FLASH (rx) : ORIGIN = 0x08002000, LENGTH = 248K

I also modified my target's system_stm32f3xx.cpp file to change the vector table offset to:
#define VECT_TAB_OFFSET 0x2000 /*!< Vector Table base offset field.
This value must be a multiple of 0x200. */

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 Could we integrate a test like @monkiineko describes above into the mbed OS test suite?

[bscott-zebra]

@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.

STM32F303xC-VectorTest.zip

[theotherjimmy]

Thanks for the detailed description of what testing you have done. We will give this a good look for inclusion in the general mbed OS test suite.

[bridadan]

@theotherjimmy Not 100% sure, especially if we have to keep a bootloader that's been compiled for every target we want to test. If the "bootloader" was just one instruction that jumps to the application that might be possible.

[0xc0170]

retest uvisor

[0xc0170]

cc @bcostm @adustm @LMESTM @jeromecoutant

[bcostm]

Testing the RAM vector adress instead of the Flash looks ok to me.

[adbridge]

retest uvisor

[0xc0170]

/morph test

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 359

All builds and test passed!