I'm using the RTX RTOS and I noticed that in the latest version there is a new feature which is a stack high water mark. I've been able to use this while debugging in the IDE but was wondering if there's a way to get this information from the RTOS so that I can monitor this in normal operation? Currently I have my own stack monitoring thread that uses the RTOS' task control block structure to manually calculate stack usage but if I could grab this high water mark data instead then my stack monitor thread could be slimmed down considerably. So, if anyone knows where within the RTOS this high water mark data resides or how to access it please let me know.
Thanks
Yes, so the stack monitor thread runs when no other threads are active so it can only ever see the other threads' stacks when they're in an idle state.
I see where you're coming from with the idea of a high priority interrupt to capture each threads' stack usage while it's active. That might be the next revision of our stack monitor.
So I guess there isn't any way to access the stack high water mark data that is in this latest version of RTX? Will there be plans to add this to each thread's task control block in future versions of RTX?
Thanks, Doug
Doug, thanks for explanation. It looks like you are looking for a feature that "warns" you in the run-time system when a certain stack load is exceeded.
As you know, we have today a stack protection that stops the system when a thread stack overflows. Looks like this is not enough to cover your requirements.
I will discuss this with the development team.
Thanks! I wouldn't say that the stack overflow protection in the RTOS isn't enough for our software rather the maximum stack usage is just nice to have for our monitoring and logging scheme that we implement. Again this isn't essential it's just a nice to have feature and since the stack high water mark is new I just wondered if it would be available to use to speed up and simplify our current monitoring scheme.
Remember that unless the hardware has special support for it, the only normal way to check how much stack a task consumes is to either - poll the stack pointer at a reasonably high frequency - to fill the stack with a magic pattern and scan how much of the pattern that has been overwritten - to instrument the generated code with special prologue/epilogue code that checks the consumed stack when calling/returning.
An OS can detect an overrun stack by placing magic values directly after the stack end and check if this pattern has been modified. But except for that, it can only sample the stack pointer at situations where it gets involved. So when a time slice is over, or when you call one of the OS functions. And if it hooks all interrupts, it could sample the usage even if there is no explicit OS call.
So the best in your case would, in my view, be either a high-priority interrupt sampling the stack usage. Or a low-priority background task that checks for amount of overwritten magic values. The low-priority route has the advantage that it mostly just affects the amount of power a bit - unless it gets totally starved so it never gets a chance to collect any information. The disadvantage with it is that it can only tell usage - but have no idea what code path that might represent the costlies call tree.