In case the selected frequency is higher than the requested one, it is
better to send a debug warning rather than an blocking error.
In case of such warning, user may need to redefine the clock tree setting
at higher level (reducing peripheral's input clocks during init phase).
Up to now, speed was set for outputs and alternate, but this is
also valid for input configuration.
By default, let's configure high speed.
This is done firts, because speed for some families like F1 is mixed
with Input/Output mode settings, so can be later over-ridden if needed.
By default the number of pstorage pages is set 1 and all addresses are
calculated in the pstorage module accordingly. Nordic recommends
changing this macro to whatever number is suitable for the app (see
https://devzone.nordicsemi.com/question/53066/what-will-be-the-starting-
address-of-pstorage-page-how-we-can-change-it/?answer=53085#post-id-5308
5) which is not quite elegant given that pstorage_platform.h is part of
the mbed-os repo. With this modification you can e.g. define
PSTORAGE_NUM_OF_PAGES on the command line, however note that you should
rebuild mbed-os with this setting as it affects pstorage_platform.c.
This patch will prevent building bootloader builds on targets that have
not yet had their linker scripts/scatter files changed to allow for the
ROM space shrinking expected by bootloader builds. At the point of this
patch, bootloader linker script modifications are only supported by the
NUCLEO_F429ZI, K64F, KL46Z, and Odin.
Check in flash algos for the K64F, KL46Z, F429, F439 and Odin board
and enable these features accordingly in targets.json. This
implementation uses flash algo blob that are generated via scripts.
The K64F and KL46Z were generated directly from packs, while the
KL46Z, F429, F439 and odin were generated from code checked into
the FlashAlgo repo.
I modified the bug in PR #3289. But It seems not enough the changes.
For the reason, It occured the following issue.
https://github.com/ARMmbed/mbed-os/issues/3694
So I reviewed and re-modified about the setting of initial value of interrupt edge in "gpio_irq_init".
The address of the vector table is hardcoded to the start of flash in
many, if not all, ST targets. This causes a crash in applications that
are using a bootloader. This patch updates the boards STM32F429xI,
STM32F439xI and Odin so they properly handle updating the VTOR with
a bootloader.
The pwmout driver is very similar for each STM32 family.
The only family specific part is defined in pwmout_device.h file.
It mainly contains few specific information:
- The mapping of PWM/TIMERS to APB1 or APB2 so that we can get the clock
- The clock calculation uses the right APB clock, which was sometimes
not the case before and could have lead to errors in case dividers were
enabled on APB clock settings. This case is now covered.
- Inactivation of inverted support on feaw families
The default pin mode shall be set as part of the pinamp_pinout, and
as defined in tables of PeripheralPins.c, but this is currently
over-written by a call to pin_mode(pin, PullNone); from
mbed_pinmap_common.c, so we need a set the mode again here, including
OpenDrain config as needed for I2C.
this first makes pinmap.c a common file
then rework it with several goals:
- avoid gpio / irq / pin management extra dependencies
- improve performances when switching between pin modes
This change is based on LL layer to access to registers level
instead of using HAL higher level API.
The family specific functions are implemented in pin_device.h
of each family. Mostly this is F1 family that is differnt
from other ones.
Instead of using HAL_GPIO_Init / Deinit which makes a lot of registers
being written and re-written, and which creates extra gpio / pin / irq
dependencies, we directly set the IRQ related registers thanks for the
STM32 LL layers which provides APIs to modify registers.
The NCS36510 is limited to 16bit timers. Construction of larger
intervals is performed in software by counting the number of 16bit
intervals that pass.
Either this counting takes a bit of time, or there is a math error
somewhere (maybe a long critical section?), because there is a
roughly ~1us delay between when the interrupt occurs and the ticker
progresses onto the next 16bit interval. This is normally a completely
reasonable error, except that the error accumulates. After a while,
the equeue tests find themselves with tens of milliseconds of error.
To make matters worse, this error is random because of other interrupts
occuring in the system, making the exact issue quite a bit difficult
to track down.
This fix drops the software counter in favor of just recalculating
the next delay interval from the target time and value of the running
timer. The running timer used to calculate the current tick is left to
overflow in hardware and doesn't have this drift.
In case of prescaler_rank was 0, a -1 index was being used,
which resulted in initialization of the Init.BaudRatePrescaler with
random values.
Now let's better check index and avoid -1 operation, so that prescaler_rank
can be only from 0 to "last_index".
Add MBED_APP_START and MBED_APP_SIZE to the Odin's linker script
so the start and size of an image can be specified. This allows the
ROM to be split into a bootloader region and an application region.
Add MBED_APP_START and MBED_APP_SIZE to the stm32f429's linker script
so the start and size of an image can be specified. This allows the
ROM to be split into a bootloader region and an application region.
Add MBED_APP_START and MBED_APP_SIZE to the K64F's linker script
so the start and size of an image can be specified. This allows the
ROM to be split into a bootloader region and an application region.
Martin Kojtal
jeromecoutant
bcostm
adustm
Mohammad Azim Khan
Głąbek, Andrzej
Mike Fiore
Laurent MEUNIER
Hovik Melikyan
Sam Grove
U-ONSEMI\fg64rh
Pierre-Marie Ancele
Jimmy Brisson
Christopher Haster
Russ Butler
pradeep-gr
0xc0170
TomoYamanaka
Russ Butler
Liviu Ionescu
ccli8