This patch adds BLE Cordio support into MBED HAL. It contains:
* Cordio and TRIM object files
* The Cordio stack header file
* The Cordio library for Beetle Systems precompiled for GCC and ARMCC
The BLE implementation will be provided in a future patch in the mbed-os
repository.
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
In Beetle systems eFlash and Cache Flash are always enabled by default.
This patch updates the Mbed SDK Init procedure to reflect the changes in
the eFlash and Cache Flash Drivers provided in a previous patch.
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
This patch adds BLE Cordio support into CMSIS. It provides:
* A modification for the linker scripts for both ARMCC and GCC
compilers that adds the cordio specific sections.
* A method to access the Flash stored MAC Address.
The CORDIO_RO_2.1.o and TRIM_2.1.o objects that rappresent the Cordio
firmware will be added by a future patch.
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
In Beetle systems eFlash and Cache Flash are always enabled by default.
This patch refines the interface of these drivers to match the
functionalities exposed by the platform.
This patch renames also writel/readl in these drivers to uppercase to follow
acros code convention.
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
- changing device.h -> targets.json after rebase
- adding startup and config files for ARM_STD toolchain
- changing all STM32F7xx targets to ARM as default toolchain (instead of uARM before)
- nrf headers synchronized with the one in BLE implementation. This is a
short term fix. The nordic branches use a single nrf SDK and does not
have duplicate headers. Once this branch will be integrated, there will
be no more issues around duplicate headers.
- enable feature BLE in the targets.json. This fix was done a long time
ago in the nordic branch. Without it, it is not possible to compile BLE
examples.
Issue #2074
Assuming that OverSampling is initialized, the baudrate is now correctly
computed inside CMSIS (STM32 HAL) layer. This was not the case before but
most probably was fixed during latest L0 cube firmware upgrade:
commit ce436d5107
Author: svastm <simon.vanson@st.com>
Date: Thu Apr 14 14:39:53 2016 +0200
Update STM32CUBE_L0 from v1.2 to v1.5
- __heap_size__ was used to allocate a fixed size region for the heap in
RW_IRAM1
- __user_setup_stackheap in sys.cpp uses Image$$RW_IRAM1$$ZI$$Limit as the
start of the heap, which leaves the fixed size region unused
Update of STM32L4 family CPI clock selection algo.
Maximum SPI clock is obtained from APB domain clock (based on HAL API).
Then algo sets maximum frequency available below requested frequency
Update of STM32L1 family CPI clock selection algo.
Maximum SPI clock is obtained from APB domain clock (based on HAL API).
Then algo sets maximum frequency available below requested frequency
Update of STM32L0 family CPI clock selection algo.
Maximum SPI clock is obtained from APB domain clock (based on HAL API).
Then algo sets maximum frequency available below requested frequency
Update of STM32F7 family CPI clock selection algo.
Maximum SPI clock is obtained from APB domain clock (based on HAL API).
Then algo sets maximum frequency available below requested frequency
Update of STM32F3 family CPI clock selection algo.
Maximum SPI clock is obtained from APB domain clock (based on HAL API).
Then algo sets maximum frequency available below requested frequency
Signed-off-by: Erwan GOURIOU <frq07517@st.com>
Update of STM32F1 family CPI clock selection algo.
Maximum SPI clock is obtained from APB domain clock (based on HAL API).
Then algo sets maximum frequency available below requested frequency
Update of STM32F0 family CPI clock selection algo.
Maximum SPI clock is obtained from APB domain clock (based on HAL API).
Then algo sets maximum frequency available below requested frequency
Update of STM32F4 family CPI clock selection algo.
Maximum SPI clock is obtained from APB domain clock (based on HAL API).
Then algo sets maximum frequency available below requested frequency
Introducing ADC2 support for NUCLEO_F446ZE implies to have the support
in the core part for all F4 chipsets that possibly support it (even if
not supported on all boards).
If you don't specify the start address of a section explicitly, that
section can end up at different addresses depending on its alignment. If
the alignment of a section is not explicitly set, it inherits it from
the element with the highest alignment inside that section.
Since the uVisor code is in the .text section, and it *must* end up at a
known location, we set the start address of .text to 0x410, which is the
value that the uVisor binary expects.
This patch enables RTOS support on Beetle.
It contains:
* Updated Beetle Startup code for ARMCC
* Modified SysTick Driver
* RTOS specific configuration parameters
* RTOS specific test suite enablement
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
The current version of MBED test environment requires LEDs to be present
in the platform.
Beetle HW does not provide any user programmable LEDs. This patch provides an
emulation of the feature by using dummy PINs.
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
This patch adds support for BEETLE SoC Target into the HAL layer.
It contains:
* Beetle Platform Configuration
* I2C API
* SPI API
* Serial API
* Port API
* us Ticker API
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
This patch adds support for BEETLE SoC Target into the CMSIS layer.
It contains:
* Beetle System Core
* APB DualTimer Driver
* APB Timer Driver
* eFlash Driver
* Flash Cache Driver
* ARM Toolchain Support
* GCC ARM Toolchain Support
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
This fix is a solution for issue #816 when having two separate IRQ handlers
in Timers (UPDATE Irq and OutputCompare Irq). The update priority needs to
be higher to avoid undefined behaviours.
Change-Id: Ic143ed0f3e4e42ad5f7b95337d8c005b7ec61274
This fix is a solution for issue #816 when having two separate IRQ handlers
in Timers (UPDATE Irq and OutputCompare Irq). The update priority needs to
be higher to avoid undefined behaviours.
Change-Id: I5ef2c27926167ed22108901cd63586692a5f8f90
This is a partial revert of 07b841b and currently we are only reverting the
STM32F0xx family because new fix will be presented that's why we want to keep,
still the original solution only F1xx family (it will be fixed in future).
Change-Id: I147065299310c9fea499bf3ced8808a44699a1a1
This is backwards-compatible with unsupported targets.
If an application is compiled using the K64F target without uVisor
(UVISOR_PRESENT not set or set to 0) then uvisor_init() will just be an
empty function that immediately returns.
This commit includes all sections that are just added to the linker
script. These changes are backwards-compatible, meaning that they will
not affect the existing code.
Targets that do not support uVisor will leave those sections empty.
Freescale KSDK2 gpio_object.h pulled in Freescale libraries to inline
some GPIO operations.
The resulting namespace pollution (status_t) doesn't seem to be worth
the function call overhead. Hopefully making the base address array
non-automatic will offset that loss.
mbed TLS requires an entropy source, and this provides support for one through
the K64F RNG.
The macro MBEDTLS_ENTROPY_HARDWARE_ALT also added to target.json to enable use
of the entropy collector by mbed TLS.
Due to directory structure change, modification in e93878078 was made wrong
after rebasing the code.
This reverts commit e938780788 and updates path
to the correct file.
Note:
Current value of TIM_MST->CNT is read in interrupt context only.
This avoids master timer overflow without SlaveCounter update.
Continuation of patch: 07b841b08f
Change-Id: Iab0341847130f86e16500fd85024b6a87525fe14
Added CAN API support for NUCLEO_L476RG target.
"stm32l476xx.h" file was changed to avoid compilation errors.
Change-Id: Ifadf7048f6c72c0311ec915e47ce2190460ede68
Added CAN API support for DISCO_L476VG target.
*stm32l476xx.h* file was changed to avoid compilation errors.
NOTE: MBED_29 or MBED_30 cannot be tested on this platform because CAN pins are
soldered to USB, GYRO and others.
Change-Id: I2e85bd36dc45872b1ab617f072de98164f2c96f8
With this change, the heap section occupy the whole space from the end of
the bss section to the start of the stack section instead of taking a
fixed size in RAM.
This change allows applications to make a more efficient use of the RAM
available and allows application to be compiled if the space between end
of bss and start of stack is less than 2048 bytes.
Following cube update, there has been changes in cube HAL that impact
the serial_api.c layer. The global state has been moved to separate
global/tx and rx states, so we can now differentiate both.
The NRF51 doesn't have a systick. When the MCU doesn't have a systick, the
HAL has to export several functions which will be use by the kernel to
manage the tick:
* os_tick_init provides the initialization function for the alternative
hardware timer.
* os_tick_val returns the current value of the alternative hardware timer.
* os_tick_ovf returns the overflow flag of the alternative hardware timer.
* os_tick_irqack is an interrupt acknowledge function that is called to
confirm the alternative hardware timer interrupt.
The HAL should also call OS_Tick_Handler needs to be called as the
hardware timer interrupt function.
In the case of the NRF51, two RTCs are available:
* RTC0: reserved for soft device
* RTC1: used by us_ticker.
RTC1 is a 4 channels timers, channel 0 is used for us_ticker, and
in this port channel 1 is used for tick generation.
Implementation notes:
* RTC1_IRQHandler: has to be written in assembly otherwise a stack
overflow will occur because the function OS_Tick_Handler never
returns. This function is called when RTC1 channel IRQ is triggered.
* tick generation has been optimised for a tick with a duration of
1000us.
* us_ticker can still be compiled and used without RTX enabled.
More information about alternative timer as RTX Kernel Timer:
https://www.keil.com/pack/doc/CMSIS/RTX/html/_timer_tick.html
The KSDK2 update restricts static data to the first 64K of RAM.
This breaks some applications which require more than 64K of
static data. This patch moves the static data sections
(bss and data) into the second ram region which is 192K.
Changes taken from similar patches here:
https://github.com/ARMmbed/target-kinetis-k64-gcc/pull/5https://github.com/ARMmbed/target-kinetis-k64-gcc/pull/6
Previous layout
---------------
0x1FFF0000 m_data .interrupts_ram
0x1FFF0400 data, bss
0x1FFFFFFF end of bss
0x20000000 m_data_2 start of heap, end of stack
0x2002ffff end of heap, start of stack
New layout
----------
0x1FFF0000 m_data .interrupts_ram
0x1FFF0400 start of unused ram
0x1FFFFFFF end of unused ram
0x20000000 m_data_2 data, bss
0x200XXXXX end of bss
0x200XXXXX+1 start of heap, end of stack
0x2002ffff end of heap, start of stack
When the function spi_master_write is called a transfer will occur
and set the end of queue flag. This disables further SPI transfers
which causes the next SPI transfer to hang forever.
This patch clears the end of queue flag so SPI does not hang after
the first transfer.
Address passed into the mbed I2C API are expected to be 8 bit and
include the read/write flag. KSDK2 expects a 7 bit address without
this flag. This patch shifts the address passed into the KSDK by 1
so it is in the correct format.
On repeated starts the flag to indicate this is not being set
properly. Because of this the transfer fails. This patch
keeps track of the last transfer to determine if a repeated
start should be sent and sets the KSDK flags appropriately.
- Resetting in LPCXpresso IDE did not reset the LCD controller which
sometimes could cause strange behaviour
- The ROM_LAT bit in the MATRIXARB register must be set in order to
prevent a HardFault when debugging
- The change of compiler in LPCXpresso IDE to ARM launchpad GCC5 was
causing build errors due to multiply defined timeval symbol.
- The exporters for LPCXpresso IDE did not set the FPU_PRESENT define
for assembler, only for c/c++. This caused very strange behaviour
in the RTOS code (e.g. timeouts no longer working, context switches
failing etc.)
In repeating start scenarios, there was a bug in the I2C driver for
various NXP LPCxxxx parts which could allow an extra I/O from the
previous operation to leak through. The scenario I encountered which
triggered this bug went like so:
* The higher level application code would first do an I2C write that
doesn't send a stop bit (use repeating start instead.)
* The higher level application code would then issues an I2C read
operation which begin with a call to i2c_start().
* i2c_start() would clear the SI bit (interrupt flag) at the top of
its implementation.
* i2C_start() would then get interrupted right after clearing the SI
bit.
* While the CPU is off running the ISR code, the I2C peripheral
repeats the last byte written to I2CDAT and then sets the SI bit to
indicate that the write has completed.
* The ISR returns to allow the i2c_start() to continue execution.
* i2c_start() would then set the STA bit but it is too late.
* i2c_start() waits for the SI bit to be set but it is already set
because of the completed byte write and not because of the repeated
start as expected.
For me this bug would cause strange interactions between my ISRs and
the code using I2C to read from the MPU-6050 IMU. I would be getting
valid orientation data and then all of a sudden I would start receiving
what looked like random values but I think it was just reading from the
incorrect offset in the device's FIFO.
It appears that atleast one other person has seen this before but it
was never root caused since it required specific timing to reproduce:
https://developer.mbed.org/forum/bugs-suggestions/topic/4254/
This bug can be found in most of the NXP I2C drivers and this commit
contains a fix for them all. I however only have the LPC1768 and
LPC11U24 for testing.
My fix does the following:
* No longer clears the SI bit in the i2c_conclr() call near the
beginning of the i2c_start() function. It was this clear that
previously caused the problem as described above.
* The second part of the fix was to instead clear the SI bit after
the STA (start) bit has been set with the i2c_conset() call.
* The clearing of the SI bit should be skipped if there isn't an
active interrupt when first entering i2c_start(). If you clear
the SI bit when there isn't an active interrupt then the code
is likely to skip over the interrupt for the start bit which was
just sent and then allow the I2C peripheral to start sending the
slave address before it has even been loaded into the I2CDAT
register.
We need to remove *can_api.c* file accordingly to new directory structure.
Without that we can't compile any CAN mBed test.
Change-Id: I3d4f798ad75ec1b4c4a1d7ed877e71b7db6bf60f
This path fixes issue #816.
Current value of TIM_MST->CNT is read in interrupt context only.
This avoids master timer overflow without SlaveCounter update.
Change-Id: I8e2ec02ce7539a4c044c7e3dfe6bedc9fcdf7736
This path fixes issue #816.
Current value of TIM_MST->CNT is read in interrupt context only.
This avoids master timer overflow without SlaveCounter update.
Change-Id: Iaaf7b9eb33aa8d8992e9354ca5e21bf01ec2413d
This path fixes issue #816.
Current value of TIM_MST->CNT is read in interrupt context only.
This avoids master timer overflow without SlaveCounter update.
Change-Id: Ie7a9bfce76990f85caa84264450d053604af33e5
Both STM32F0xx and STM32F1xx are using a 16-bit timer as a internal ticker
but the mBed ticker needs a 32-bit timer implementation, so the upper part
of that 32-bit timer is being calculated in software.
Software bug has been fixed where continous HIGH/LOW voltage levels
could be observerd for 65ms due to 16-bit timer overflow.
Now current value of TIM_MST->CNT is stored in cnt_val and is
updated in interrupt context only. This avoids master timer
overflow without SlaveCounter update.
This fix is only for platforms which already implements a 16-bit timer:
F103RB, F070RB, F030R8
Change-Id: I205c70ce155b373c6593ead93ade9ec38993f7f9
Added CAN API support for NUCLEO_F302R8 target.
*stm32f302x8.h* file was changed to avoid compilation errors.
Change-Id: Ia4ee8a90fe3f0ad6955dde21e78ea4a6c05e4fcd
Added CAN API support for NUCLEO_F303K8 target.
*stm32f303x8.h* file was changed to avoid compilation errors.
Change-Id: If093c84f19c5a5ef68938af4653a25271c1108ba
Added CAN API support for NUCLEO_F303RE target.
*stm32f303xe.h* file was changed to avoid compilation errors.
Change-Id: Ia6519c982261d43165dbce73cab7cfc0617474e2
Added CAN API support for NUCLEO_F334R8 target.
*stm32f334x8.h* file was changed to avoid compilation errors.
Change-Id: Ic7b3273ffe24940ecdc189d2566a6a7f66825ce6
Laurent Meunier
Martin Kojtal
Aksel Skauge Mellbye
Steven Cooreman
Andrzej Głąbek
Michel Jaouen
Vincenzo Frascino
Andrzej Puzdrowski
adustm
svastm
ohagendorf
Vincent Coubard
Laurent MEUNIER
Jarek Zgoda
Sam Grove
Christopher Haster
Mahadevan Mahesh
Colin Hogben
tomoyuki yamanaka
Erwan GOURIOU
Mike Fiore
Rohit Grover
Laurent MEUNIER
Simon Hughes
Bartosz Szczepanski
Alessandro Angelino
Niklas Hauser
Andrii Anpilogov
Maciej Bojczuk
bcostm
Russ Butler
jeromecoutant
Kevin Bracey
Simon Butcher
Jimmy Brisson
Russ Butler
Jerome COUTANT
Anders Lindvall
Adam Green
Rafal Kula
Mihail Stoyanov