|
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). Thanks, Pete |
|
|
CW Debugger Stack Window Question
Started by ●May 6, 2003
Reply by ●September 9, 20042004-09-09
|
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 our 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 do not represent any code. Sometimes I've seen the name of an unused ISR there, but breakpoints in that 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 To: 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). Thanks, Pete _____________________________________ 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: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ |
|
|
Reply by ●September 14, 20042004-09-14
|
Rick, 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 one. Basically I found that the debugger gets confused when things are pushed on the stack. When stepping through code, the stack window changes drastically 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 hear 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 our 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 do not represent any code. Sometimes I've seen the name of an unused ISR there, but breakpoints in that 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 To: 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). Thanks, Pete _____________________________________ 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: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ _____________________________________ 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: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 Yahoo! Groups Links |
|
|
Reply by ●September 15, 20042004-09-15
|
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 stored). 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 one. > Basically I found that the debugger gets confused when things are pushed on > the stack. When stepping through code, the stack window changes drastically > 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 hear > 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 our > 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 do > not represent any code. > > Sometimes I've seen the name of an unused ISR there, but breakpoints in that > 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 > To: > 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). > > Thanks, > Pete -- 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 |
|
|
Reply by ●September 15, 20042004-09-15
|
Ron, I believe the "startup code" that you refer to is in the attached arch.c file. The "push r1" instruction on line 291 was inserted at the request of Metrowerks tech support as an attempt to solve this problem. Unfortunately it didn't do the trick. Please let me know what you find out. Thanks, Terry Litinas -----Original Message----- From: MW Ron [mailto:] Sent: Tuesday, September 14, 2004 9:18 PM To: 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 stored). 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 one. > Basically I found that the debugger gets confused when things are pushed on > the stack. When stepping through code, the stack window changes drastically > 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 hear > 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 our > 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 do > not represent any code. > > Sometimes I've seen the name of an unused ISR there, but breakpoints in that > 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 > To: > 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). > > Thanks, > Pete -- 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: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 Yahoo! Groups Links | |||
|
Reply by ●September 17, 20042004-09-17
|
Hi Ron 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. Thank you! Rick Corey -----Original Message----- From: MW Ron [mailto:] Sent: Tuesday, September 14, 2004 9:18 PM To: 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 stored). 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 one. > Basically I found that the debugger gets confused when things are pushed on > the stack. When stepping through code, the stack window changes drastically > 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 hear > 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 our > 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 do > not represent any code. > > Sometimes I've seen the name of an unused ISR there, but breakpoints in that > 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 > To: > 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). > > Thanks, > Pete -- 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: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 Yahoo! Groups Links |
