static stack analysis

A catchall for PSoC Mixed-Signal Array (microcontroller) discussions not captured by the other forums.

Moderator: ericb

Rating

Excellent
2
33%
Very Good
2
33%
Good
2
33%
Fair
0
No votes
Poor
0
No votes
 
Total votes : 6

static stack analysis

Postby steve on Mon Dec 15, 2003 11:20 am

Here's a nifty progamming utility. It reads ImageCraft listing files and calculates maximum stack depths needed for the program. It has a few limitations like a clunky output format and can't handle jacc instructions or calls through function pointers. Details are in readme.txt. The source is included.

Steve

http://www.psocdeveloper.com/downloads/stackwalk.zip
steve
Cheese Cube
Cheese Cube
 
Posts: 55
Joined: Thu Dec 11, 2003 4:44 pm

Postby EdwinOlson on Mon Dec 15, 2003 1:13 pm

Very cool.

A clarification/question: the 2nd number is the maximum size of the stack needed for all code paths leading from that instruction?

i.e., if we look at the 2nd number under "main", that's typically the # we're interested in as far as "how much stack space do I use". Is that right?

It would be even more useful if you could call it with the # of bytes available and it would print the call sequences that cause problems.

It also doesn't handle recursion very well. If you did the above, it might be possible to harvest the maximum # of recursions permissible.
-Ed
EdwinOlson
Bite-Size Cheese
Bite-Size Cheese
 
Posts: 16
Joined: Mon Dec 15, 2003 1:05 pm

Postby steve on Mon Dec 15, 2003 3:51 pm

Thanks.

The readme.txt file in the test/output directory has a description of the fields.

In the execution path listing, the first number is the current stack depth, the second number is the max stack depth along all execution paths from that point, and the third number is the next PC value along the path to the max stack depth.

It's more complicated in the annotated program listing, and possibly wrong. The numbers in the complete listing were meant to be high water marks from all the passes from interrupt locations. It turns out that the sets of addresses reachable from the different interrupt vectors can overlap That makes things harder to interpret.

I like the idea about reporting execution paths that exceed a certain limit value.

Steve
steve
Cheese Cube
Cheese Cube
 
Posts: 55
Joined: Thu Dec 11, 2003 4:44 pm

Postby EdwinOlson on Tue Dec 16, 2003 6:14 am

how about printing out--to the console--the maximum depth seen, to avoid having to look in the output files?
EdwinOlson
Bite-Size Cheese
Bite-Size Cheese
 
Posts: 16
Joined: Mon Dec 15, 2003 1:05 pm

how to get stack.lst?

Postby justslightlyconfused on Wed Dec 17, 2003 5:54 am

Dumb question, but how do I create the stack.lst file for my project?

Thanks!
justslightlyconfused
Newbie
Newbie
 
Posts: 4
Joined: Wed Dec 17, 2003 5:53 am

Postby steve on Wed Dec 17, 2003 9:07 am

To run stackwalk, build a PSoC Designer project and then run stackwalk as a command-line application in the project's output directory. If the project is named "project", the command line looks like this:

stackwalk project.lst stack.lst paths.lst

There's a new version that prints the maximum depths seen to the console. The source and executable are in the same place:

http://www.psocdeveloper.com/downloads/stackwalk.zip

Steve
steve
Cheese Cube
Cheese Cube
 
Posts: 55
Joined: Thu Dec 11, 2003 4:44 pm

don't have 'em

Postby justslightlyconfused on Wed Dec 17, 2003 10:05 am

I've tried both designer 3.21 and 4.0 and they are only making project_name.lst (and the hex, dgb, etc.)... no stack.lst or paths.lst.

Is there an option somewhere?
justslightlyconfused
Newbie
Newbie
 
Posts: 4
Joined: Wed Dec 17, 2003 5:53 am

oops

Postby justslightlyconfused on Wed Dec 17, 2003 10:08 am

Oh, you are CREATING the stack.lst and path.lst. That could be made clearer.

Sorry!
justslightlyconfused
Newbie
Newbie
 
Posts: 4
Joined: Wed Dec 17, 2003 5:53 am

Postby craign on Wed Dec 17, 2003 11:04 am

Steve, you're just going to have to improve the documentation for your quick hacks. 8)
regards,
-Craig
User avatar
craign
The Big Cheese
The Big Cheese
 
Posts: 231
Joined: Thu Dec 11, 2003 7:51 pm
Location: Between Jeff (formerly Steve) and Galen (formerly Eric)

Thank you

Postby justslightlyconfused on Thu Dec 18, 2003 6:58 am

My complaining about documentation aside, this is a great tool. Very helpful.

Thank you!
justslightlyconfused
Newbie
Newbie
 
Posts: 4
Joined: Wed Dec 17, 2003 5:53 am

Postby PyeAreSqrd on Fri Dec 19, 2003 6:08 pm

can the stack analyzer determine max stack usage with interrupts? Put another way, will it find the max stack under non-interrupt conditions then analyze all interrupts and add to see the absolute max stack usage?
PyeAreSqrd
Bite-Size Cheese
Bite-Size Cheese
 
Posts: 15
Joined: Thu Dec 11, 2003 4:51 pm

Postby mrzee on Tue Jan 06, 2004 4:54 pm

Interrupts occur asynchronously to the code and the maximum stack usage can be calculated by calculating the stack usage of every interrupt and getting the maximum one then add this as a constant offset to the previously calculated stack depth.

N.B. This can ONLY work under the following condition:

No ISR EVER re-enables interrupts.

If it does then to calculate stack useage requires a PSoC simulator that can simulate all possible interrupt sources and the external hardware that triggers the interrupts. This would have to be run over an extreamly long time to get an accurate representation of stack usage. Needless to say it would be easier to test the device using the ICE to check stack depth.

Regards,
MrZee
User avatar
mrzee
The Big Cheese
The Big Cheese
 
Posts: 384
Joined: Mon Jan 05, 2004 5:59 pm
Location: Virginia, USA

Postby mrzee on Wed Jan 07, 2004 8:55 pm

Hi Steve,

Just tried using the stackwalker program on a project that is running low on RAM.
Found one little hiccup with it, it seems to get confused it there is any flash based data tables within the code. Though the data never gets executed as it's bracketed by ret instructions the program calculates the stack usage for it.
In my case it came up with a stack depths of 0x7F and 0x76 and 0x75 for the reset vector , vect 0x0c and vect 0x38 respectfuly. As my RAM varibles finish at 0x96 and the project does work I thought I'd let you know.
It was easy enough to correct the figures by tracing through the listing manually.


***edit***
Did some more checking, the inline data isn't inline data at all!
It's the EEPROM module code. Looks like your code works correctly after all. The EEPROM allocates an extra 73 bytes of stack space if the write data isn't exactly 64 bytes. In my case the data is always 64 bytes but the stackwalker program doesn't know that. Subtracting the 73 bytes out of each one of the larger results corrects the situation to the way it should be.


Great program, I like the fact you broke each int vector into seperate threads, this makes it very handy even in my case where I must re-enable interrupts.

Thanks!

Regards,
MrZee
User avatar
mrzee
The Big Cheese
The Big Cheese
 
Posts: 384
Joined: Mon Jan 05, 2004 5:59 pm
Location: Virginia, USA

Postby baxsie on Mon Jun 14, 2004 6:00 am

I tried to run this utility, but it hangs here:
Code: Select all
stackwalk: warning - jacc instruction not traced at address 0x077b
stackwalk: warning - jacc instruction not traced at address 0x0943
stackwalk: warning - jacc instruction not traced at address 0x357a
stackwalk: warning - jacc instruction not traced at address 0x04a0
stackwalk: warning - jacc instruction not traced at address 0x0381
stackwalk: error - stack overflow at 0x380f from 0x380d
^C

until I break it (the ^C).

Any ideas on that one?

I was also wondering how hard it would be to support JACC tables. What if we were to force in a comment, or use some special format for the target labels . . . could the stack walker then pick those out and trace them?

This is a particular issue for me since my greatest stack depth is expected inside a jump table.
baxsie
The Big Cheese
The Big Cheese
 
Posts: 420
Joined: Mon Dec 22, 2003 10:08 pm

Postby supercat on Tue Jun 15, 2004 7:59 am

baxsie wrote:I was also wondering how hard it would be to support JACC tables. What if we were to force in a comment, or use some special format for the target labels . . . could the stack walker then pick those out and trace them?


I would expect that the key would be for the program to be somehow informed of the possible values of A when the jacc was executed.

BTW, I would expect that the stack-walker would also have difficulties with RETs that go back somewhere other than immediately following the last CALL [e.g. as a result of code that pushes a return address and does a RET].
supercat
Cheese Wheel
Cheese Wheel
 
Posts: 117
Joined: Thu Feb 19, 2004 6:14 pm

Postby steve on Tue Jun 15, 2004 8:32 am

You're right, the issue with JACC instructions is knowing the possible values of A. I was thinking of passing the information in a separate input file, but using a special comment format is a better idea.

SSC instructions have the same issue. The stack space used depends on the value of A and on the part number. It seems a little easier to figure out than JACCs (given the part number), since the SSC code is usually loaded into A immediately before the SSC opcode.

Functions that do indirect calls by modifying their return address are another problem. This can happen in state machines implemented with C calls through function pointers, or can be set up directly by assembly code. For that, I think what's needed is a list of the possible target functions for each indirect call.

Steve
steve
Cheese Cube
Cheese Cube
 
Posts: 55
Joined: Thu Dec 11, 2003 4:44 pm

Postby steve on Tue Jun 15, 2004 8:54 am

baxsie wrote:I tried to run this utility, but it hangs here:
Code: Select all
stackwalk: warning - jacc instruction not traced at address 0x077b
stackwalk: warning - jacc instruction not traced at address 0x0943
stackwalk: warning - jacc instruction not traced at address 0x357a
stackwalk: warning - jacc instruction not traced at address 0x04a0
stackwalk: warning - jacc instruction not traced at address 0x0381
stackwalk: error - stack overflow at 0x380f from 0x380d
^C

until I break it (the ^C).

Any ideas on that one?

The error is saying that stackwalk found a potential loop in the code that increases stack depth each time around the loop. The addresses given are the last link in the loop.

It looks like the last link is a 2 byte instruction at 0x380d which is followed by an instruction at 0x380f and there is some execution path from 0x380f back to 0x380d that pushes more than it pops. The path may exist but be logically impossible, since stackwalk always traces both paths from a conditional jump as it doesn't know any of the runtime data values or condition codes. Alternately, some combination of data might cause the program to execute the loop and corrupt the stack.

Stackwalk stops tracing execution paths when it runs into a loop like this, but seems to go into an infinite loop of its own in response. How ironic. Oh well, more to debug ...

Can I get a copy of the project or listing file to help track this down?

Steve
steve
Cheese Cube
Cheese Cube
 
Posts: 55
Joined: Thu Dec 11, 2003 4:44 pm

Postby antedeluvian on Wed Feb 23, 2005 8:26 am

Steve

I seem to be having some kind of setup problem using stackwalker. On both the earlier and later downloads there are two different versions of stackwalker.exe in the unzipped files (in the Debug and Release folders), and although the results differ slightly for each I am sure the problem must be the same. I have copied the stackwalker.exe to the output folder of a project (I have tried this on several projects with the same results) and in a DOS window I run the stackwalk in the project's output folder as you describe in the readme. The projects have been built using PSoC Designer 4.2 SP1.

When I try this on projects created on earlier versions of PSoC Designer it seems to work.

I get an abnormal progam termination notice after the following screen output:

stackwalk: error - listing file flash image gap or overlap error at line 5854
stackwalk: error - listing file flash image gap or overlap error at line 5855
stackwalk: error - listing file flash image gap or overlap error at line 5856
stackwalk: error - listing file flash image gap or overlap error at line 5857
stackwalk: error - listing file flash image gap or overlap error at line 5858
stackwalk: error - listing file flash image gap or overlap error at line 5859
stackwalk: error - listing file flash image gap or overlap error at line 5860
stackwalk: error - listing file flash image gap or overlap error at line 5861
stackwalk: error - listing file flash image gap or overlap error at line 5862
stackwalk: error - listing file flash image gap or overlap error at line 5863
stackwalk: error - listing file flash image gap or overlap error at line 5864
stackwalk: error - listing file flash image gap or overlap error at line 5865
Assertion failed: 0 <= addr && addr < g_vcFlashImage.size(), file C:\swdev\syst
ms\utilities\stackwalk\stackwalk.cpp, line 196

Have you any idea what I am doing wrong?

Regards
Aubrey
antedeluvian
The Big Cheese
The Big Cheese
 
Posts: 248
Joined: Mon Dec 22, 2003 12:03 pm
Location: Toronto, Canada

Postby craign on Wed Feb 23, 2005 9:30 am

Steve is on vacation. He'll be back next Monday. I put a sticky on his monitor... you should hear something early next week...
regards,
-Craig
User avatar
craign
The Big Cheese
The Big Cheese
 
Posts: 231
Joined: Thu Dec 11, 2003 7:51 pm
Location: Between Jeff (formerly Steve) and Galen (formerly Eric)

Postby steve on Mon Feb 28, 2005 11:18 am

There are two problems I know of that can produce the "gap or overlap" error message, but neither matches the error messages from your project exactly.

One is source files that aren't terminated with carriage-return/linefeeds. If a project has files like this, sometimes the listing file generator appends first disassembly line of the next file to that line instead of putting the disassembly on a line by itself. This messes up the listing file parser which reports an error.

The other is absolute areas. If a program has code up in high flash far above the rest of the program (like a bootloader), the gap between the end of the relocatable areas and the bootloader area will be reported as an error.

I think both of those scenarios produce isolated errors. You're seeing a sequence of errors from consecutive line numbers, which looks more like an overlap of some sort (either in the listing file or in stackwalk's interpretation of the listing file).

I'd be interested in taking a look at the problem and seeing if it's fixable. Is it possible to send me the listing file, may attached to either a forum post or private message?

Regards,
Steve
steve
Cheese Cube
Cheese Cube
 
Posts: 55
Joined: Thu Dec 11, 2003 4:44 pm

Next

Return to PSoC1 General

Who is online

Users browsing this forum: Bing [Bot] and 0 guests