Initialization steps in toolchains #2917
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 6 commits
October 4, 2016 14:55
Various toolchains supported in MBED don't follow the same initialization steps. This can have impacts on platform behavior. For STM32, it is needed to call the HAL_Init() _after_ the RAM has been initialized (sdata from flash / zero initialized data) and _before_ the C++ objects are being created, especially if those objects require support of tickers for instance. In GCC, this is easily done because SystemInit is called after the ram initialisation, so HAL_Init does not need to called from mbed_sdk_init. this is covered by the changes in mbed_overrides.c files. This series should solve issue reported here: STM32 (At least F401) breaks if Tickers are activated in a global object ARMmbed#2115
Various toolchains supported in MBED don't followthe same initialization steps. This can have impacts on platform behavior. For STM32, it is needed to call the HAL_Init() _after_ the RAM has been initialized (sdata from flash / zero initialized data) and _before_ the C++ objects are being created, especially if those objects require support of tickers for instance. In GCC and IAR, this was done in previous commit to avoid HAL_Init() to be called twice. In ARM this there is no hook defined in MBED yet to place the call. The proposal is to take benefit of the library's _platform_post_stackheap_init function that is going to be called before __rt_lib_init where the C++ object init is done (__cpp_initialize__aeabi_) This series should solve issue reported here: STM32 (At least F401) breaks if Tickers are activated in a global object ARMmbed#2115
In uARM, the library's hook _platform_post_stackheap_init does not seem to exist and I couldnot find a documentation describing the initialisation flow. All we know is that _open is called after RAM init and before the C++ init, so this is a working placeholder. This is maybe not acceptable so a uARM lib expert may propose a better hook to fullfil the requirement. At least this is a workign setup. This series should solve issue reported here: STM32 (At least F401) breaks if Tickers are activated in a global object ARMmbed#2115
Various toolchains supported in MBED don't followthe same initialization steps. This can have impacts on platform behavior. For STM32, it is needed to call the HAL_Init() _after_ the RAM has been initialized (sdata from flash / zero initialized data) and _before_ the C++ objects are being created, especially if those objects require support of tickers for instance. In GCC and IAR, this was done in previous commit to avoid HAL_Init() to be called twice. In ARM this there is no hook defined in MBED yet to place the call. The proposal is to take benefit of the library's _platform_post_stackheap_init function that is going to be called before __rt_lib_init where the C++ object init is done (__cpp_initialize__aeabi_) In case of mbed with rtos, the __rt_entry is redefined so we need to add the call to _platform_post_stackheap_init. This series should solve issue reported here: STM32 (At least F401) breaks if Tickers are activated in a global object ARMmbed#2115
In this commit we're moving the mbed_sdk_init call before the RTOS initialisation so that the sequence is similar to other toolchains.
Supported toolchains initialization steps have been modified to make sure that mbed_sdk_initi is called _after_ RAM initialization and _before_ C++ objects creation. since this was done, there is no need to redundant SystemCoreClockUpdates in the drivers
|
/morph test |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 1054 All builds and test passed! |
sg-
added
ready for merge
release-version: 5.2.0
and removed
needs: CI
ready for merge
labels
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Rebase #2160 on to master in perpetration for the release.
Todos