We are using ThreadX through the CMSIS2 layer provided here with USE_DYNAMIC_MEMORY_ALLOCATION.
When we delete a task, we call osThreadDetach() and then osThreadTerminate(), expecting this to free the memory that was allocated when we called osThreadNew(); however this is never the case, and we soon run out of memory.
You can see this if you set break-points here:
|
osStatus_t osThreadTerminate(osThreadId_t thread_id) |
...here:
|
_tx_thread_system_preempt_check(); |
...and here:
|
if (thread_ptr->tx_thread_detached_joinable == osThreadDetached) |
The first two break points are reached when osThreadTerminate() is called, status is 0 at the second break-point but, the last break-point is never reached, presumably because _tx_thread_system_preempt_check() has done its stuff, task-switching has occurred, the code that follows the call to tx_thread_terminate() is never going to be run.
How is this meant to work?
FYI, we have tried calling tx_thread_preemption_change() and tx_thread_priority_change() with zero before terminating that thread, to set the current thread to top priority (0 in ThreadX terms), which this post suggests should effectively create a critical section, but that doesn't change the behaviour, _tx_thread_system_preempt_check() still chooses to switch to what is now a lower-priority (54 in ThreadX terms) thread.
This tested on a Nucleo STM32F575ZI board, in case it matters.
We are using ThreadX through the CMSIS2 layer provided here with
USE_DYNAMIC_MEMORY_ALLOCATION.When we delete a task, we call osThreadDetach() and then osThreadTerminate(), expecting this to free the memory that was allocated when we called osThreadNew(); however this is never the case, and we soon run out of memory.
You can see this if you set break-points here:
STM32CubeU5/Middlewares/ST/cmsis_rtos_threadx/cmsis_os2.c
Line 1458 in f0f0631
...here:
STM32CubeU5/Middlewares/ST/threadx/common/src/tx_thread_terminate.c
Line 307 in f0f0631
...and here:
STM32CubeU5/Middlewares/ST/cmsis_rtos_threadx/cmsis_os2.c
Line 1485 in f0f0631
The first two break points are reached when
osThreadTerminate()is called,statusis 0 at the second break-point but, the last break-point is never reached, presumably because_tx_thread_system_preempt_check()has done its stuff, task-switching has occurred, the code that follows the call totx_thread_terminate()is never going to be run.How is this meant to work?
FYI, we have tried calling
tx_thread_preemption_change()andtx_thread_priority_change()with zero before terminating that thread, to set the current thread to top priority (0 in ThreadX terms), which this post suggests should effectively create a critical section, but that doesn't change the behaviour,_tx_thread_system_preempt_check()still chooses to switch to what is now a lower-priority (54 in ThreadX terms) thread.This tested on a Nucleo STM32F575ZI board, in case it matters.