|
Hi, all, When I use -s option(strip symbolic information) in the c6x linker under ccs2.0 I can not load the program into the C6203 DSP. But if I do not use -s option the program can be loaded into DSP smoothly. The error message is: "unexpected fatal error encountered which may have been caused by stack overflow, out of memory condition or access violation". Which things can incur this case? I have check all my arrays.The stack is 1024 bytes while all my functions use about 210 words stack. Wang Tao R&D Engineer ShangHai Orda -- |
|
|
about strip symbolic information in c6x linker
Started by ●February 17, 2003
Reply by ●February 17, 20032003-02-17
|
Tao Wang- > When I use -s option(strip symbolic information) in the > c6x linker under ccs2.0 I can not load the program into > the C6203 DSP. But if I do not use -s option the program > can be loaded into DSP smoothly. The error message is: > "unexpected fatal error encountered which may have been > caused by stack overflow, out of memory condition or > access violation". Which things can incur this case? I > have check all my arrays.The stack is 1024 bytes while > all my functions use about 210 words stack. What if you try a really small program, just some init code? It may be that CCS so much expects symbol information (for debug purpose) that it just cannot deal with no symbol info. If you get it down to just a few lines and the error still occurs, you might submit to TI and see what they say. Jeff Brower DSP sw/hw engineer Signalogic |
|
|
Reply by ●February 21, 20032003-02-21
|
hi, I am woring on TMS320c6201 DSP processor uning CCS V2. I am currently writing a program on the 6201 EVM. I have encountered a problem which I need some help with. There is a function in my project called rem_dc() which is called by main(). This function is in the same C file as main(). This is my C file where I call my funtion rem_dc ( ). #include<stdio.h> main() { rem_dc ( ); // call my function } rem_dc( ) { } When I profiled the function (rem_dc( ) ), it took 3500 clock cycles (with o3 potimization.). I then moved rem_dc( ) to a separate file in the the project. From the main file, I called the fuction rem_dc ( ). I then ran the program (again with o3 optimization). rem_dc() took 23,000 cycles. Why is there such a large difference? All my sections(data, program,etc) in the.cmd file are in internal program memory. Thanks Mos ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com |
Reply by ●February 21, 20032003-02-21
|
Mohammed Samdani- Did you look at the generated asm code for the call? And also for the function? If there is a significant difference in the asm instructions, it should be easy to see because the code is so simple. Please let me know what you find. Jeff Brower DSP sw/hw engineer Signalogic > I am woring on TMS320c6201 DSP processor uning CCS V2. > > I am currently writing a program on the 6201 EVM. I > have encountered a problem which I need some help > with. There is a function in my project called > rem_dc() which is called by main(). This function is > in the same C file as main(). > > This is my C file where I call my funtion rem_dc > ( ). > > #include<stdio.h> > main() > { > > rem_dc ( ); // call my function > > } > > rem_dc( ) > { > > } > > When I profiled the function (rem_dc( ) ), it took > 3500 clock cycles (with o3 potimization.). > > I then moved rem_dc( ) to a separate file in the the > project. From the main file, I called the fuction > rem_dc ( ). I then ran the program (again with o3 > optimization). rem_dc() took 23,000 cycles. > Why is there such a large difference? > > All my sections(data, program,etc) in the.cmd file > are in internal program memory. > > Thanks > Mos |
