mirror of https://github.com/ARMmbed/mbed-os.git
INIT:ARM + rtos: Align pre-main initialization steps between TCs
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 #2115pull/2917/head
parent
e8d67ac530
commit
3a61bd025f
|
@ -538,6 +538,7 @@ void pre_main (void)
|
|||
__asm void __rt_entry (void) {
|
||||
|
||||
IMPORT __user_setup_stackheap
|
||||
IMPORT _platform_post_stackheap_init
|
||||
IMPORT os_thread_def_main
|
||||
IMPORT osKernelInitialize
|
||||
#ifdef __MBED_CMSIS_RTOS_CM
|
||||
|
@ -558,6 +559,7 @@ __asm void __rt_entry (void) {
|
|||
/* Ignore return value of __user_setup_stackheap since
|
||||
* this will be setup by set_stack_heap
|
||||
*/
|
||||
BL _platform_post_stackheap_init
|
||||
BL osKernelInitialize
|
||||
#ifdef __MBED_CMSIS_RTOS_CM
|
||||
BL set_stack_heap
|
||||
|
|
Loading…
Reference in New Issue