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
Hi Doug,
what is your thread monitoring? The system has in general stack protection. The Watermark feature allows you to optimize stack usage. What exactly do you need?
Once we understand that we may consider it in future versions.
Thanks Reinhard
Hi Reinhard,
I have a thread that I use to monitor all active thread's current and maximum stack usage. The monitor thread does this by running a simple calculation using the thread's current stack pointer and the known size of the stack. It also keeps track of the maximum stack usage it sees for any particular thread. But if this data already exists in the form of the stack high water mark then I could avoid these calculations thereby speeding up my monitoring thread. The monitoring thread runs in the idle state. I should also mention that whenever the monitor thread sees a thread's stack usage go over 50% then we record this in a log we store on an attached EEPROM chip. The entry in EEPROM tells us what thread exceeded the limit and by how much. We've implemented this monitoring thread as a debugging tool and so we can fine tune our threads' stack requirements. Like I mentioned, if the data already exists in the form of the stack high water mark I would ideally be able to use this data instead of calculating this myself. This would speed up the monitoring thread enabling it to catch stack overflows earlier.
Thanks, Doug
Note that an IDLE thread will only run when no other thread has anything to do.
So if it looks at the stack pointer for any other thread, it will only be able to see the stack pointer when the monitored thread have reached an idle state, i.e. when it is sleeping in a delay or waiting for events/messages/... So you will never see the fancy call trees when it processes any received data.
So for an OS that doesn't has specific support for watermarks, you instead need a high-priority interrupt running from a reasonably fast-ticking timer that will check current thread and current stack pointer value for that thread. Then you will be able to get samples even when runnable threads are deep into call trees (assumming you sample often enough and it isn't too seldom/short time that threads do deeper call nesting (or maybe not so deep nesting but with significant local state).
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?
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.