Hello, I use RTX166 on my system (20 tasks). How can i check Task Stack busy level to prevent a possible stack overflow? Operating system manual say: "Register R0 is stack pointer" I will check Run-time R0 value to find max value. but I think is much better to use a Source Code Analyzer like: http://www.absint.com/stackanalyzer but it doesn't work with Keil. Can you suggest me a stack analyzer for my system? Best Regards
One way to test stack usage is to fill the stack memory area with a certain data pattern at program startup, stress-test the program and then review stack memory area to see how much of the initial pattern was overwritten. This will give you an idea of maximum stack usage. - mike
Mike, your post is dangerous. It should have been: This will give you an idea of maximum stack usage but usually a rare situation will use more. I have see a stack overflow problem in a product that showed up on average once every 3 months. Erik
I should probably have used a disclaimer like "Use my advice at your own risk" :-) OK, I really meant 'an indication of stack usage'. I'll try to be more careful next time. But to be fair, maybe if the developers of the product you mentioned used the techneque I suggested then there wouldn't be any stack overflows there at all? Cheers! - mike
It is a good idea. Reading from manual, standard task use a common working stack area; So when there is a context change the runnig task save stack somewhere (I don't understand where) and a waked-up task use working stack area. So I can check saved stack and/or running stack. I think is better to test saved stacks becouse the runnig stack have this problem: In case a task 1 use stack at 90% and task 2 take control and use stack at 20% the copy of task 2 stack on working area clean the action of task 1. Somebody know where are mapped stacks saved? FM Regards
Use the online manual: http://www.keil.com/support/man/docs/tr166/tr166_stackmgmt.htm Having looked at the page myself, I am not sure now that the technique I suggested can be used effectively with this kind of stack management. With all those stacks shrinking and expanding and moving around there is a good chance of all of the stack area being overwritten even with plenty of stack space to spare. Or maybe I'm missing something... - mike
I'm using RTX-166 Full, not tiny My manual is RTX-166 Real-Time Multitasking Executive for the 166/167 Microcontroller Family User's Guide 2.2000
Mike, your statement was totally correct, it just happens that I have seen, more than once, this technique applied to establish "max needed stack size" without ANY calculation of the worst case. In many instances, you can run the product for days without encountering worst case. Worst case (which happens "once a month") is: int a (the stack hungriest of those at priority 3) interrupting int b (the stack hungriest of those at priority 2) that interrupted int c (the stack hungriest of those at priority 1) that interrupted int d (the stack hungriest of those at priority 0) This, I believe, has been the most common of the things that "failed once a month" I have been asked to look at. When I see some post that - in any way - can be misapplied and cause a problem I have seen, I have this annoying habit of emphasizing. Erik