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.
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.
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.
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
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
Remember that unless the hardware has special support for it, the
only normal way to check how much stack a task consumes is to
- 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.
This Knowledgebase-Article offers an idea in which the calculated
stack size left for each thread is made accessible for a further
That's great... exactly what I was looking for. I will incorporate
this into my code.
View all questions in Keil forum