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.
The field device_name is intended to match that of a target in a
device family pack. Remove this field for devices which do not have
a pack. Fix the name for devices that have the name incorrect. Update
IAR definitions for device which no longer have a device_name but
still need to have support for the IAR exporter.
* Adding Cortex-A support for gnuarmeclipse
* Preventing '-mthumb' from being added to Cortex-A builds.
Previously, both '-mthumb' and '-marm' were being supplied to the
compiler (in that order). Because '-marm' came last, the compiler
respected this option. This change makes it so '-mthumb' is added for
all 'Cortex-M' targets only.
* Renaming to capital .S for Eclipse compatibility
With the RTOS, the STACK_SIZE specified here is unrelated to the stack
size available for the main thread (that runs pre_main). Save memory by
reducing the stack size to a more reasonable amount.
On uVisor, HEAP_SIZE is both a minimum available and maximum available
heap size. The heap can't grow beyond the end of the heap into the
neighboring stack. On all uVisor-supported platforms, guarantee at least
0x6000 bytes of heap space. This increases the portability of uVisor
applications as the memory available for legacy heap allocations is
guaranteed. This helps to avoid out of memory errors on platforms that
were previously guaranteeing less memory.
this I2C IP is meant for automatic STOP, based on programmed number
of bytes to be sent or receivede, not a user triggered STOP.
So the state machiine needs to be reset in case we use this I2C mbed
unitary API (start / byte_write / byte_read / stop).
Only one point of attention:
STM_MODE_ANALOG_ADC_CONTROL is a specific mode that is only supported on L4.
So STM_MODE_ANALOG_ADC_CONTROL was moved to index 13 (last entry)
of gpio_mode table so that all the other modes are common and only the last
one is specific.
SystemInit() was called condititionally, but necessary defines were not
set in mbed. Calling SystemInit() unconditional now.
Removed also conditiional calls to legacy CodeRed lib.
A copy paste error snuck into the uVisor related updates to the EFM32GG
linker script. Fix the error by replacing "m_data" with "RAM".
Fixes: 89641bc7e0 "uVisor: Update K64F and EFM32GG linker scripts"
Add sleep/deepsleep functions to platform layer which are replacing HAL
functions with the same name, rename existing symbols in HAL layer
to hal_sleep/hal_deepsleep. This way sleep functions
are always available, even if target doesn't implement them, which makes
the code using sleep clearer. It also enables us to make decision on in
which builds (debug/release) the sleep will be enabled.
When building with the debug profile, certain ST plaforms error with
'get_i2c_timing' not being defined. This is because the function is not
defined as 'static inline', but just 'inline'.
Let's make the code more common for gpios.
The only difference between STM32 families is that BRR register may
not be available. In case BRR is not available, we use the 16 left bits
of BSRR instead. We could always use BSRR, but BRR saves one left-shift
operation, so let's use it when available.
By default we will consider using BRR, except for platforms that define
GPIO_IP_WITHOUT_BRR.
Following HAL update, this is needed to use the I2C API function
rather than previously used MACRO.
An assert would fail at compilation time otherwise.
This commit improves consistency between different platforms' linker
scripts. In particular, we use "__UVISOR_SRAM_START" instead of
"__UVISOR_BSS_START" as the uVisor BSS sections might be outside of the
SRAM (for example, when using a tightly-coupled memory).
Previously, when "length = 0" as failsafe, "return 0" is executed.
But we changed so that only START bit and STOP bit are executed same as other devices.
Laurent MEUNIER
bcostm
Głąbek, Andrzej
Hovik Melikyan
Sam Grove
U-ONSEMI\fg64rh
Pierre-Marie Ancele
Jimmy Brisson
Christopher Haster
jeromecoutant
Russ Butler
Martin Kojtal
pradeep-gr
0xc0170
TomoYamanaka
Russ Butler
Liviu Ionescu
ccli8
Helmut Tschemernjak
Brian Daniels
Jaeden Amero
Michel Jaouen
Bartek Szatkowski
Helmut Tschemernjak
mbedNoobNinja
adustm
Mahesh Mahadevan
Jesse Marroquin
JojoS
TsungtaWu
Anna Bridge
Brian Daniels
Mike Fiore
Alessandro Angelino