We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I have a weird problem with my CMSIS-RTOS RTX application. Application consists of 3 threads with user-provided stacks.
osThreadDef(USBRead, osPriorityHigh, 1, 300); osThreadDef(DCMotorDrive, osPriorityAboveNormal, 1, 400); osThreadDef(ScanProduct, osPriorityNormal, 1, 200);
With this configuration, everything goes smoothly. All threads are created, first runs USBRead thread, which blocks on empty Mail queue. After that, DCMotorDrive starts running and so on.
However, if I change USBRead stack to 200 bytes, debugger says that DCMotorDrive thread is in stack overflow. That happens as soon as USBRead blocks and thread switch begins. If I put a breakpoint on the very beginning of DCMotorDrive thread, it never reaches it.
Does anybody have experience with this? Is it some bug in debugger (that actually USBRead thread got to stack overflow), or something I have overlooked?
RTX does not check stack all the time - only during task switching. I supsect that reducing USB thread stack caused it to overwrite DCMotor tasks's data or even kernel data and then it is wrongly detected as DCMotor task overflow.