STM32 (At least F401) breaks if Tickers are activated in a global object

[Sissors]

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 ;).

[0xc0170]

cc @bcostm @adustm @LMESTM

[LMESTM]

@Sissors in my to-do list
do you know if this happens on any toolchains or a specific one ?

[Sissors]

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.

[LMESTM]

I have the issue reproduced on several toolchains - so I will have a look next week, starting with Sissors' hints

[LMESTM]

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:
#2129
By cherry-picking the commit of this PR, I have a successful test on IAR.
You may try it out, but not sure how to do this from online compiler

I will look now at GCC / ARM / µARM and try to find a fix as well

[LMESTM]

I v'e posted PR #2160
from my tests results so far, together with #2129, it solves the issue on all TCs