We added "IPV4" of Compile Macro in "targets.json" file.
We failed in the reletion test of IPV4 because "IPV4" was not entered into our Build Target setting.
- __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).
stdin converts the following character sequences:
\n -> \n
\r\n -> \n
\r -> \n
\n\r -> \n
For original behaviour, a serial object can be instantiated explicitly
stdout converts the following character sequences:
\n -> \r\n
\r\n -> \r\n
\r -> \r
\n\r -> \n\r
For original behaviour, a serial object can be instantiated explicitly
This is a hack to get debug builds applications that use uVisor to work.
The assertions in core_util_critical_section fail because interrupts can't
actually be disabled from unprivileged mode.
Without this hack, core_util_critical_section_enter() calls
mbed_assert_internal() when the assertion fails, which calls
core_util_critical_section_enter() again, which calls
mbed_assert_internal() again; this is infinite recursion.
core_util_critical_section_enter needs some fixing.
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 malloc lock functions were not declared as extern "C" so they
are not getting linked to the standard library. Add extern "C" to
fix this.
This bug was introduced in the commit:
d0b7b3b497 -
Fix duplicate symbols for malloc lock and unlock
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 patch adds support for the BEETLE Target. The compilers supported by
this target are:
* ARMCC
* GCC ARM
The exporters and the CMSIS/HAL components will follow in future patches.
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
Add a virtual destructor to classes which have a virtual lock and
unlock. Remove the virtual qualifier from functions in
InterruptManager since this class cannot be extended.
When the malloc lock and unlock functions are inside a library they
conflict with the standard libraries weak version of these functions.
This is because of the way weak references are handled by the linker.
This patch renames the lock and unlock functions defined inside RTX
so they do not conflict. A thunk inside retarget.cpp then calls the
RTX functions. This problem does not occur with retarget.cpp since
it is always build into an object file rather than a library file.
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.
uvisor-lib has an init function that must be called before the RTOS kernel
is initialized. Call uvisor_lib_init from software_init_hook to accomplish
this.
Wrap software_init_hook so that it can be used or extended from outside the
RTOS. This is desirable so that code can be added to the software_init_hook
without making the RTOS depend on new features or libraries.
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.
"features" will make more sense in the context of the feature support
that we'll introduce later (related to #1878). Plus, "device_has" is
arguably a better description of the actual content of this key.
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
Cortex-A does not contain primask, there's 7th bit in the CPSR register,
that contains this information. Fixes#1851.
Renames primask variables to interrupts_disabled.
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
Add the locks and flags necessary to make the IAR standard library
thread safe. These changes consist of:
-Add compiler flag "--guard_calls" to ensure C++ function-static
variables with dynamic initializers are initialized in a
thread safe manner
-Add the linker flag "--threaded_lib" so the thread safe version of
the standard library is used
-Implement mutex functions required for IAR thread safety
-Create a set of stub functions in retarget.c for when the rtos is not present
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.)
Routines using __disable_irq and __enable_irq had the effect of
enabling interrupts if called with interrupts disabled.
Some versions of __disable_irq do not return old status to restore it.
Change to use the critical section helper functions instead.
This includes a generic critical section implementation. This
implementation also allow a user to start a critical section while
interrupts are already disabled.
per @c1728p9
Update the Callback class to handle a NULL thunk by returning 0
rather than trying to call the thunk. This fixes a crash that occurs
on some targets when the TX uart handler is not attached.
Background:
The K64F HAL uart implementation calls the TX interrupt handler
every time a uart interrupt occurs while the TX register is empty.
It does not check to see if the TX interrupt has been enabled.
This means that the TX interrupt can and typically does get
run on RX events. This causes a crash with the newer callback
code which did not (prior to this patch) support a NULL thunk.
- Adopt C++11 style template arguments, requires rename to Callback
- Add constructor for C style callback functions
- Add constructor for Callbacks
- Add static function for passing to C style callbacks
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
This was causing errors at my machine (for programs like MBED_10, RTOS_1):
Error[Li005]: no definition for "__semihost" [referenced from
semihost_api.o(mbed.a)]
[ERROR] Error[Li005]: no definition for "__semihost" [referenced from
semihost_api.o(mbed.a)]