I am using RTX 4.70 for a project on Cortex M-3. I have added some osXXX calls to the core RTX api.
I am finding that if I have 2 threads (in addition to main plus any timer thread or idle thread) and one is blocked on say an osDelay(), the other thread bombs when it enters kernel mode via a svc trap. I am seeing some form of stack smashing. If I increase OS_TSKCNT from 3 to 4, the problem goes away, but I fear I am postponing a later stack corruption, and that the extra TSK_CNT memory block is buying me some time.
Looking through the RTX4 sources, I am not quite sure whether each thread gets both its own thread mode stack, i.e. tracking PSP, AND its own handler mode stack, tracking MSP, or if there is a single kernel stack and ALL threads 'share it'. Surely for each thread to enter handler mode and exit from it, a dedicated handler mode stack space is needed.
I cannot quite fathom from RTX_Conf_CM.c which #define, if any, is supposed to let me 'increase my handler mode stack space'.
ANY help appreciated. I am using GCC toolchain on Linux, so I don't have an RTX-aware debugger alas. i think at this point that would be very useful.
Stu
OS_TSKCNT needs to include the main thread also. If you make an app with nothing but a main thread you need an OS_TSKCNT needs to be at least 1. Timer Thread and Idle thread do not need to be included in this count.
It is "OK" for main() to return safely and terminate, but that has not always been the case. Not so many years ago main() returning would cause the whole system to crash. I would prefer to see an explicit ThreadTerminate(), an osDelay(osWaitForever) or just never terminate. Just stating my preference, not a right way / wrong way of doing it.
Yes, I can see now that OS_TSKCNT should include main.
As with so many scenarios of this type of debugging, I was on the wrong path for quite a while. I wasn't stack smashing at all, but now I am more aware of stack requirements, so this has been a good exercise.
For anyone interested in a 'don't do it like this':
1 An ISR calls os_signalSet( T, S); on a thread T but that thread had already exited (called osThreadExit())
2 ISR sets PendSV and exits
3 PendSV tries to decide who to run and sees a corruption in the RTX data structs, since the os_signalSet did some nasty updates (I haven't quite worked out what)
4 PendSV encounters a Hard Fault.
Curiously, and again I am not fully aware of why, if I bumped OS_TSKCNT to one more that the thread count I actually needed, I would 'get away with' the error condition, but of course not sure for how long.
The problem was in my application code, as is usual ;)