STM32L5x2xx processor.
STM32CubeIDE
Version: 1.10.1
Build: 12716_20220707_0928 (UTC)
Program structure:
Main.c calls CPP_LINK (a C++ routine) that enables system level drivers (with ThreadX mutexes), then starts main ThreadX task.
C++ classes own ThreadX objects (mutex, queue, task pointer). Class init routine creates ThreadX objects. ThreadX task is not inside class, but is outside.
Packet class owns TX_QUEUE, initializes it. Queue object size is less than 16 32 bit words.
Instance of packet class creates queue properly (using common byte pool in processor memory). When packet class instance runs, all is good until packet is placed on queue. Thread monitor immediately shows entire allocated stack for that task as occupied. This is regardless of actual number (2046 fills up as does 24000).
Rest of system behaves badly after this.
Actual problem can be isolated to the macro where the ThreadX queue actually transfers from the source (which is correct), to the destination (which matches pointers in queue structure. That macro running seems to kill everything. I suspect that the "to" pointer owned by the queue is incorrect.
WORKAROUND: Create TX_QUEUE as global object and initialize/create from C routine (not part of ThreadX task, not C++ code, is created in bridge routine that eventually initializes main system task. Stack does not overflow in this instance.
Philosophy of the program is to bridge to C++. Program is uses many queues and C++ classes to do graphics, and main routine is responsible for creating (as configured) these queues. Note that this all works under FreeRTOS without a problem.
Comments welcome:
