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
[XDOT_L151] copy new target CMSIS files from NZ32_SC151 target
[XDOT_L151] remove Modtronix code, add HardFault_Handler, update clock configuration to match xDot hardware
[XDOT_L151] copy new target HAL files from NZ32_SC151 target
[XDOT_L151] update HAL to match xDot hardware
[XDOT_L151] add xdot_eeprom.* and xdot_low_power.* files
[XDOT_L151] add RTOS support for target
Conflicts:
rtos/rtx/TARGET_CORTEX_M/RTX_Conf_CM.c
[XDOT_L151] match NUCLEO_L152RE startup code for GCC_ARM so RTOS works
[XDOT_L151] fix GPIO write failure
[XDOT_L151] add XDOT_L151CC target to targets.json
[XDOT_L151] change xDot default stack size to 256 bytes and main stack size to 1.5kB
[XDOT_L151] update PinNames.h to match rev E hardware - no change to external pinout
[XDOT_L151] update style in custom xDot HAL files
Conflicts:
rtos/rtx/TARGET_CORTEX_M/RTX_CM_lib.h
rtos/rtx/TARGET_CORTEX_M/RTX_Conf_CM.c
Before:
Callback<void()> a = callback(obj, member)
Callback<void()> b = callback(context, function)
After:
Callback<void()> a = callback(obj, member)
Callback<void()> b = callback(function, context)
This ordering is more intuitive based on feedback from users. This order
was initially considered but proved problematic when integrated with
other variable arguments in attach functions.
With `callback` as a separate convenience function, this style
no longer presents a problem.
Before, rtx calls would hard fault in critical sections when an svc
instruction was attempted with interrupts disabled.
Required changes:
- Added check for CPSR I bit in cortex A rtx
- Added check for PRIMASK in cortex M rtx
- Modified critical sections in cortex M rtx to be recursive
(already recursive in cortex A)
Disintegrate global RTX target config. Move per-target fragment
to mbed_rtx.h under each vendor's directory.
One mbed_rtx.h is defined for each vendor at this moment, however,
the granularity of mbed_rtx.h can be per-chip, or per-board
if necessary.
Signed-off-by: Tony Wu <tung7970@gmail.com>
Update the Thread::start function to gracefully handle the failed
creation of a thread when there are no TCBs left. This patch does
the following:
1. Set memory handles to NULL after free to prevent double free
2. Post to the release semaphore so anything that tries to join this
thread will join immediately
3. Remove dead return path since the new operator should never
return NULL (it should trap instead)
Add an RTX hook which gets called when a thread terminates. Add
the function Thread::attach_terminate_hook() to allow users to attach
a hook to this event at runtime.
Add the function osThreadGetInfo to allow various Thread information
to be queried. This includes stack size and maximum stack usage among
other things.
Note - for Cortex-A devices the worst case stack usage is not
available.
Add the functions osThreadsEnumStart, osThreadEnumNext and
osThreadEnumFree to allow enumeration of running threads. Protect
thread creation, thread exit and thread termination with a mutex
so threads are not created or destroyed while an enumeration is
ongoing.
Bartek Szatkowski
Jimmy Brisson
Christopher Haster
Anna Bridge
Russ Butler
Sam Grove
Wolfgang Betz
TomoYamanaka
Sarah Marsh
sarahmarshy
Mahadevan Mahesh
Laurent MEUNIER
Mike Fiore
Rob Meades
jeromecoutant
Tony Wu
Vincent Coubard
Martin Kojtal
Russ Butler
andreas.larsson