STM32 (At least F401) breaks if Tickers are activated in a global object #2115
Comments
|
@Sissors in my to-do list |
|
Assuming my guess of the root cause (that function in mbed_override), it should depend on when it is called. I haven't tested it on anything besides the online one (which is essentially the Keil compiler, not sure if you have set ARM or uARM as default for the F401). I suppose it is somewhere in one of compiler specific startup files defined, but to answer your question: No I am not aware if this affects every toolchain. |
|
I have the issue reproduced on several toolchains - so I will have a look next week, starting with Sissors' hints |
|
Hi, As said I have reproduced the problem on all toolchains - with a simple test based on pindetect usage. The issue is indeed related to the call to HAL_Init from mbed_sdk_init in mbed_overrides.c file. The initialization steps vary from one toolchain to another : system init, ram init, call to mbed_sdk_init and C++ object init are not ordered in the same way from one toolchain to another. In case of IAR, there is already a PR related to this: I will look now at GCC / ARM / µARM and try to find a fix as well |
|
I can confirm this on F411 |
|
ARM Internal Ref: IOTMORF-138 |
LMESTM
pushed a commit
to LMESTM/mbed
that referenced
this issue
Aug 29, 2016
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
LMESTM
pushed a commit
to LMESTM/mbed
that referenced
this issue
Aug 29, 2016
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
LMESTM
pushed a commit
to LMESTM/mbed
that referenced
this issue
Aug 29, 2016
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
LMESTM
pushed a commit
to LMESTM/mbed
that referenced
this issue
Aug 29, 2016
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
c1728p9
pushed a commit
to c1728p9/mbed-os
that referenced
this issue
Oct 4, 2016
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
c1728p9
pushed a commit
to c1728p9/mbed-os
that referenced
this issue
Oct 4, 2016
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
c1728p9
pushed a commit
to c1728p9/mbed-os
that referenced
this issue
Oct 4, 2016
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
c1728p9
pushed a commit
to c1728p9/mbed-os
that referenced
this issue
Oct 4, 2016
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
|
@Sissors Good to close this? |
|
Yep :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See: https://developer.mbed.org/questions/69383/How-can-I-make-mRotaryEncoder-work-on-Nu/ and the answer.
Summarized, if you make a Ticker object in a global object which also activates the Ticker (in this case the RotaryEncoder, which uses the PinDetect library), then after the global objects are initialized it stops functioning, and no future Tickers function. I assume the reason is the mbed override function which set the HAL_tick, which in turns set the Timers after they have already been initialized by the mbed lib before.
Several options: Such as only initializing it once. Or possibly, although I don't know if that would solve all issues, splitting the init of Tickers and Timers. Or any other way to unfuck it ;).
The text was updated successfully, but these errors were encountered: