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
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 #2115
This function reads the pull mode from HW and can then be used
to avoid over-writing the previously set pull-up / pull-down modes.
This is done following reported issue: #2638
Decrease the minimum space reserved for the heap from 16K down to
2K for GCC. This does not have an effect on the actual heap size since
the heap takes up all free RAM. This just allows code to compile in
configurations where the heap is smaller than 16K.
Bugs are as below.
- In the case of MTU2 mode, modify a problem that does not excute "pwmout_write ()" at the end of "pwmout_pulsewidth_us ()" function.
- In the case of MTU2 mode in "pwmout_period_us ()" function, modify a problem that the executing result of "set_mtu2_duty_again ()" function does not reflect in the register of TGRA_MATCH [] and TGRC_MATCH [].
Głąbek, Andrzej
bcostm
Sam Grove
Sarah Marsh
Christopher Haster
Laurent MEUNIER
Jimmy Brisson
Russ Butler
tomoyuki yamanaka
mtkrtk
Mahadevan Mahesh
andreas.larsson