uVisor doesn't set the PSP of the target thread. The RTOS sets the PSP
of the target thread from the target thread's TCB. However, when
interrupts of higher priority than PendSV happen between the call to
uVisor to switch boxes, and the RTOS setting PSP, the uVisor vIRQ
interrupt handler will attempt to use an invalid PSP (the PSP from
before the box and thread switch). This leads to a crash. Make box and
thread switching atomic by disabling interrupts immediately before the
box switching until immediately after the new PSP is set.
Add the attribute flash to enable priority inheritance and robust mode.
The robust flag allows mutexes held by terminated threads to be
properly released.
Wrap the file mbed_rtos_storage.h in extern "C". This allows the
functions inside rtx_lib.h to have correct definitions when included
in a C++ file.
This is required for the RTX5 error trapping.
OsEventObserver objects expect a context to be maintained per thread on
their behalf. Add this context to the thread control block and extend
the thread creation functions with the ability to supply a context.
Add the OsEventObserver mechanism. A client interested in receiving
notifications on certain OS events can register to receive notifications
with osRegisterForOsEvents. This is useful for clients like the secure
memory allocator, which observes thread switching events in order to
swap in and out different memory allocator objects.
Remove the RTOS and CMSIS files in preperation for CMSIS 5. Note that
the RTOS heap ad stack test is left since this is still applicable to
RTX5. This file can be found here:
rtos\rtx\TARGET_CORTEX_M\TESTS\memory\heap_and_stack\main.cpp
If the free memory on a device is small enough then the calculation to
determine heap size could underflow to a large value. If this happens
then malloc will never return failure and instead will cause a crash on
allocation. This patch prevents the underflow so malloc works as
expected even with low amounts of free memory.
Calling Thread::start multiple times leads to undefined behavior since
the Thread class was not designed to handle being restarted. Return an
error code if Thread::start is called a second time to prevent this
behavior.
In CI, I receive an mbed assert of stack stats by running the following commands. Its assert is TIMEOUT.
mbed test -m RZ_A1H -t GCC_ARM -DMBED_STACK_STATS_ENABLED=1 --clean --compile
mbed test -m RZ_A1H -t GCC_ARM --run -n tests-mbed_drivers-stl_features -v
So, I fixed the process of related to stack stats (osThreadInfoStackMax).The Detail contents is here.
https://github.com/ARMmbed/mbed-os/issues/3273#issuecomment-268407191
* [RZ/A1H]Support RTX v4.80 for Cortex-A and a few Malloc API
PR to update RTX to v4.80 for Cortex-A.
In the latest CI test, three tests result in an error. The cause is mainly three points
- Unsupport RTX v4.80 for Cortex-A
- Insufficient stack size of thread defined in test
- A few Lack of Malloc API in GCC
Therefore, I supported to these. For the stack size for test, @Russ already supported in PR #3362.
Reference for issue of test error is here.
https://github.com/ARMmbed/mbed-os/issues/3273
Reference for PR to update RTX for Cortex-M.
https://github.com/ARMmbed/mbed-os/pull/1702
* Revert "[RZ/A1H]Support RTX v4.80 for Cortex-A and a few Malloc API"
This reverts commit e71f79aaf2.
* [RZ/A1H]Support RTX v4.80 for Cortex-A and a few Malloc API
PR to update RTX to v4.80 for Cortex-A.
In the latest CI test, three tests result in an error. The cause is mainly three points
- Unsupport RTX v4.80 for Cortex-A
- Insufficient stack size of thread defined in test
- A few Lack of Malloc API in GCC
Therefore, I supported to these. For the stack size for test, @c1728p9 already supported in PR #3362.
Reference for issue of test error is here.
https://github.com/ARMmbed/mbed-os/issues/3273
Reference for PR to update RTX for Cortex-M.
https://github.com/ARMmbed/mbed-os/pull/1702
to mbed SDK as there are targets with Cortex-M4. This is similar to the implementation already
done for GCC ARM
Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
Various toolchains supported in MBED don't followthe 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 and IAR, this was done in previous commit to avoid HAL_Init()
to be called twice.
In ARM this there is no hook defined in MBED yet to place the call.
The proposal is to take benefit of the library's
_platform_post_stackheap_init function that is going to be called before
__rt_lib_init where the C++ object init is done (__cpp_initialize__aeabi_)
In case of mbed with rtos, the __rt_entry is redefined so we need to add
the call to _platform_post_stackheap_init.
This series should solve issue reported here:
STM32 (At least F401) breaks if Tickers are activated in a global object #2115
Martin Kojtal
Jimmy Brisson
Kevin Gilbert
Jaeden Amero
Russ Butler
Bartosz Szatkowski
Yuguo Zou
Bartek Szatkowski
Russ Butler
Christopher Haster
Anna Bridge
Sam Grove
Wolfgang Betz
TomoYamanaka
Sarah Marsh
sarahmarshy
Mahadevan Mahesh
Laurent MEUNIER