This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
hello,
I`m doing a Pitchshift program using the C6713 board and I am in a dead point.
When I`m writting the C echivalent code for the FFT functions from the DSPLIB/support in the main.c the program is working perfectly.
When I want to use the assembly language FFT functions supported by the DSP library I have only noise in the output.
I have added the headers in the main.c as:
#include <DSPF_sp_icfftr2_dif.h>
#include <DSPF_sp_cfftr2_dit.h>
I have set the runtime support library to be rts6700.lib;
For the Include Options of the C6000 Compiler I have add:
"C:\ti\CCStudio\c6700\dsplib\lib"
"C:\ti\CCStudio\c6700\dsplib\include"
"C:\ti\CCStudio\c6700\dsplib\support\fft"
"C:\ti\DSK6713\c6000\dsk6713\include"
"C:\ti\C6xCSL\include"
I have added DSPLIB under the Code Composer Studio environment by choosing dsp67x.lib from the menu Project → Add Files to Project.
I also tried to set a breakpoint at at the fcs call, but the debugger doesn`t go into the functions` code even if I try to step into it using the assembly step. So it means there are still files to be added to the program.
Do you have any ideea about what files should be added or if I have to use some .cmd special file? For the moment I have a file.cmd with Sections where I`m specifing a .data_buffer.
Any help is welcomed !
Thanks,
Monica
Monica,
If the program builds successfully, then the function is resolved. You can look in the .map file to see the address of the function where it is placed in memory. Go to the Disassembler Window and put in the name of the function, and you should see the function contents in assembly.
Monica CHIOSA said:I also tried to set a breakpoint at at the fcs call, but the debugger doesn`t go into the functions` code even if I try to step into it using the assembly step.
What do you mean that it doesn't go into the function's code? Where does it go?
Regards,
RandyP
Hello,
thanks for answering. I`ll try your suggestion.
Monica CHIOSA said:I also tried to set a breakpoint at at the fcs call, but the debugger doesn`t go into the functions` code even if I try to step into it using the assembly step.
I thought that when the program stops at the breakpoint and I`m going into it with the assembly step I`ll see the assembly language code of that function, but it simply stays there at the function call. When I`m using the Step Over it jumbs over the function as it has been executed. But when I`m running the whole program the result is not the one I`m expecting.
Thanks you again,
Monica
The DSPLIB is compiled with Optimization level O3 that eliminates symbol debug for function calls inside the DSPLIB functions. Inorder to step into the function, include the assembly source of the function directly into the project, remove the link to DSPLIB and turn on the symbollic debug -g option of the compiler while building.
The input/output buffers and twiddle factors buffers requires a specific alignment. Ensure that you are following those guidelines.
Regards,
Rahul
Rahul,
Is it not true that even with the pre-compiled library version, Monica should be able to Assembly-Step-Into the function? It might not be easy to follow other than by reading the raw assembly in the Disassembler Window, but it should still go into the function and show the code, right?
Monica,
When you use the Assembly-Step-Into feature, it will step in DSP instruction cycles and should show the Disassembler Window, maybe depending on the version of CCS you are using. But I think this will work the same on any version of CCS.
A branch instruction takes 6 cycles to reach its destination, so you may have to step 6 times before reaching the new location, and more if there are some instructions required for putting values on the stack or other preperation for the function call. This should all be visible in the Disassembler Window, though.
Regards,
RandyP