That sounds exactly like it will solve our problem. probably we got lucky
in some of the new stationeries (from a third party vendor) but not in all
of them. I'll communicate with the vendor and copy the result back to this
group when we resolve it.
From: MW Ron [mailto:]
Sent: Tuesday, September 14, 2004 9:18 PM
Subject: Re: [motoroladsp] CW Debugger Stack Window Question
Importance: Low Rick, Pete and Terry,
My apology for the delay in responding to this ongoing thread. I had to get
engineering for an answer and I didn't forward it on right away. I
apologize. I think we have the cause of the problem but without the startup
code we can only speculate.
The problem is most likely going to be in the stationeries that you
received for the customer startup. The stationeries we ship all have start
code that setup the stack properly for termination of the crawl. The
debugger will wind its way backwards through the stacks util it finds a
termination (I believe this is the value 0 where the Return address is
It does this by reading the PC, the stack, determining what kind of Stack
frame is allocated in the current function, the calculating the location of
the return address saved on the stack. It then repeats this process
backwards until the proper termination sequence is found.
Our startup code shipped with the EVM stationeries will terminate this
properly by writing a 0 to this location on the stack.
If it is not terminated properly the debugger will start unwinding into
random information. Which is by design as some assembler programmers may
need it to unwind beyond areas where compiler symbolics are located.
The term "DummyFnX" is a the default name given to assembler code that does
not have any symbolics found for it. FFFF is typically unavailable memory.
When they are unwinding here, it reports this. If this is the problem then to fix this, they should look how the stationery
they received from the 3rd party setups the stack and then compare it to the
stationery we sent and make the appropriate changes.
I hope this helps, if it doesn't please submit this as a bug report to
with the startup code and we will work on it.
Thanks and again I apologize for the delay.
Ron > This probably won't help much but I have a similar problem with CW5.1 and
> the 56F807. I worked with Metrowerks tech support for about 2 months last
> year (SR 1-49337325) and was not able to resolve the problem. After a few
> attempts at possible fixes I guess I got tired of waiting for the real
> Basically I found that the debugger gets confused when things are pushed
> the stack. When stepping through code, the stack window changes
> when registers get pushed on or pulled of the stack making it pretty much
> useless. Like I said this probably isn't much help but I would like to
> what the solution to your problem turns out to be.
> Terry Litinas
> -----Original Message-----
> From: Corey, Rick [mailto:]
> Sent: Thursday, September 09, 2004 4:54 PM
> To: 'Pete Becher';
> Cc: Gonzalez, Gil
> Subject: RE: [motoroladsp] CW Debugger Stack Window Question >
> Hi All
> I'm using CW 6.1.2, and for a while I thought the stack window (call tree)
> was repaired. It looked pretty realistic and correct while I worked with
> the EVM board (which had code in on-chip FLASH).
> Then we got three modified sets of stationary files from a vendor for our
> custom hardware (56F8357 with an external RAM chip).
> Now, the target that uses the external RAM chip for program code _and_
> data RAM (we use the chip half-and-half) has a wacky stack window, while
> other two targets are healthy (one target is for an EVM with on-chip FLASH
> for code, and the other is for our hardware with code in on-chip FLASH and
> data in external RAM.
> We see things like this when both code and data are put in external RAM:
> F@DummyFn3 (0x00080000)
> F@DummyFn1 (other addresses)
> The addresses described, like 0x00080000, always have $FFFF in them, and
> not represent any code.
> Sometimes I've seen the name of an unused ISR there, but breakpoints in
> ISR confirm that it never ran.
> Does anyone have any idea where to start to look for dependencies between
> the debugger (stack window) and target stationary files (cfg files, linker
> cmd files, init.asm, the mcp or ??? Any suggestions would be welcome.
> Any ideas on why the stack window might be fragile, in this or earlier
> versions, would also be very welcome.
> Thanks in advance for anything including speculation.
> Rick Corey
> -----Original Message-----
> From: Pete Becher [mailto:]
> Sent: Tuesday, May 06, 2003 10:47 AM
> Subject: [motoroladsp] CW Debugger Stack Window Question > Hi All,
> When I run my debugger the Stack window can show a lot of strange
> stuff. When the debugger stops at the start of main there will be 2
> to 8 functions and <Unknown>s before the normal archStart and Main
> functions. If I click on the other functions they will be at random
> locations in the middle of the various functions and nothing to do
> with start-up.
> Does anyone see this behavior in the CW debugger Stack window?
> Do you think it may be a symptom of some coding problem in my code or
> the startup code? Or is it just a CWerk?
> I am also running into starting problems, when my pFlash code gets
> bigger than about 0xD000, that I am not sure if it's related but am
> searching for a fix (I will probably post more info on this problem
> as I gather data).
Metrowerks Community Forum is a free online resource for developers
to discuss CodeWarrior topics with other users and Metrowerks' staff
-- http://www.metrowerks.com/community --
Ron Liechty - - http://www.metrowerks.com _____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.
About this discussion group:
More Groups: http://www.dsprelated.com/groups.php3
Yahoo! Groups Links