New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32F3: Remove dependence upon a specific flash vector table location #4324

Merged
merged 1 commit into from May 30, 2017

Conversation

Projects
None yet
7 participants
@monkiineko
Contributor

monkiineko commented May 15, 2017

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.

STM32F3: Remove dependence upon a specific flash vector table location
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.
@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented May 15, 2017

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

@monkiineko

This comment has been minimized.

Contributor

monkiineko commented May 15, 2017

@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

This comment has been minimized.

Contributor

theotherjimmy commented May 15, 2017

@bridadan Could we integrate a test like @monkiineko describes above into the mbed OS test suite?

@monkiineko

This comment has been minimized.

Contributor

monkiineko commented May 15, 2017

@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

This comment has been minimized.

Contributor

theotherjimmy commented May 15, 2017

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

This comment has been minimized.

Contributor

bridadan commented May 15, 2017

@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

This comment has been minimized.

Member

0xc0170 commented May 16, 2017

retest uvisor

@0xc0170

This comment has been minimized.

Member

0xc0170 commented May 16, 2017

@bcostm

This comment has been minimized.

Contributor

bcostm commented May 17, 2017

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

@adbridge

This comment has been minimized.

Contributor

adbridge commented May 25, 2017

retest uvisor

@0xc0170 0xc0170 added needs: CI and removed needs: review labels May 26, 2017

@0xc0170

This comment has been minimized.

Member

0xc0170 commented May 26, 2017

/morph test

@mbed-bot

This comment has been minimized.

mbed-bot commented May 26, 2017

Result: SUCCESS

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

/morph test

Output

mbed Build Number: 359

All builds and test passed!

@0xc0170 0xc0170 added ready for merge and removed needs: CI labels May 30, 2017

@adbridge adbridge merged commit 9c6a068 into ARMmbed:master May 30, 2017

4 checks passed

Cam-CI uvisor Build & Test Success
Details
ci/morph-test Job has completed
Details
continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment