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.
According to FFT Implementation on the TMS320VC5505, TMS320C5505, and TMS320C5515 DSP there is some code provided by TI to use the hardware FFT coprocessor on the C5515. The link in that document is broken, but I was able to find it at http://www.ti.com/lit/an/sprabb6b/sprabb6b.zip . This archive contains two assembly files, one for use with code in the C5515's ROM and one for more generic use.
Unfortunately the code as provided doesn't compile in Code Composer 7. I get more than a thousand errors like:
"../fft/src/hwafft_rom.asm", ERROR! at line 1199: [E9999] Invalid mnemonic specified AC1 = copr(#HWAFFT_COMPUTE, AC0, dbl(*AR0-)), dbl(*(AR3-T1))=AC1
I also notice it has a couple of includes at the top ("lpva200.inc" and "macros_hwa_remap.inc") that aren't provided.
The FFT coprocessor is pretty much the reason we selected this chip, and I had hoped that the code provided by TI would work. Is there a way to get this to compile under CCS7? Or is there working code available for using the FFT coprocessor?
Found the includes: https://e2e.ti.com/support/processors/f/791/t/289912
Found instructions for setting assembly language: https://e2e.ti.com/support/processors/f/791/p/528012/1929925
I am still getting warnings like:
<Linking> "../C5515.cmd", line 86: warning #10188-D: symbol "_hwafft_br" from file "./fft/src/hwafft_rom.obj" being redefined "../C5515.cmd", line 87: warning #10188-D: symbol "_hwafft_8pts" from file "./fft/src/hwafft_rom.obj" being redefined "../C5515.cmd", line 88: warning #10188-D: symbol "_hwafft_16pts" from file "./fft/src/hwafft_rom.obj" being redefined "../C5515.cmd", line 89: warning #10188-D: symbol "_hwafft_32pts" from file "./fft/src/hwafft_rom.obj" being redefined "../C5515.cmd", line 90: warning #10188-D: symbol "_hwafft_64pts" from file "./fft/src/hwafft_rom.obj" being redefined "../C5515.cmd", line 91: warning #10188-D: symbol "_hwafft_128pts" from file "./fft/src/hwafft_rom.obj" being redefined "../C5515.cmd", line 92: warning #10188-D: symbol "_hwafft_256pts" from file "./fft/src/hwafft_rom.obj" being redefined "../C5515.cmd", line 93: warning #10188-D: symbol "_hwafft_512pts" from file "./fft/src/hwafft_rom.obj" being redefined "../C5515.cmd", line 94: warning #10188-D: symbol "_hwafft_1024pts" from file "./fft/src/hwafft_rom.obj" being redefined
With these lines in my linker command file:
/* HWAFFT Routines ROM Addresses */ /* (PG 2.0) */ _hwafft_br = 0x00ff6cd6; _hwafft_8pts = 0x00ff6cea; _hwafft_16pts = 0x00ff6dd9; _hwafft_32pts = 0x00ff6f2f; _hwafft_64pts = 0x00ff7238; _hwafft_128pts = 0x00ff73cd; _hwafft_256pts = 0x00ff75de; _hwafft_512pts = 0x00ff77dc; _hwafft_1024pts = 0x00ff7a56;
Is that something I need to pay attention to? Should this commands be at the top level of the linker command file, or nested in some other section?
This is what I'm not sure about. I've add the hwafft_rom.asm file to an existing CCS7 project. That contains this at the top:
.mmregs .def _hwafft_br .def _hwafft_8pts .def _hwafft_16pts .def _hwafft_32pts .def _hwafft_64pts .def _hwafft_128pts .def _hwafft_256pts .def _hwafft_512pts .def _hwafft_1024pts .include "lpva200.inc" .include "macros_hwa_remap.inc" .C54CM_off .CPL_on .ARMS_off
As far as I know, these .defs are necessary for the linker to find the function implementations. Correct?
There is also a header file that comes with that, hwafft.h, which contains all the C declarations eg:
Uint16 hwafft_16pts( Int32 *data, Int32 *scratch, Uint16 fft_flag, Uint16 scale_flag );
These are necessary for the C compiler to know how to call the assembly functions, correct?
And so the only other place these names occur is in the linker script, which is necessary to place them in ROM:
/* HWAFFT Routines ROM Addresses */ /* (PG 2.0) */ _hwafft_br = 0x00FF6CD6; _hwafft_8pts = 0x00FF6CEA; _hwafft_16pts = 0x00FF6DD9; _hwafft_32pts = 0x00FF6F2F; _hwafft_64pts = 0x00FF7238; _hwafft_128pts = 0x00FF73CD; _hwafft_256pts = 0x00FF75DE; _hwafft_512pts = 0x00FF77DC; _hwafft_1024pts = 0x00FF7A56;
Right?
So there are two things that are confusing me here. The first are the warnings from the linker above. The second is that in the map file I see:
MEMORY CONFIGURATION name origin length used unused attr fill (bytes) (bytes) (bytes) (bytes) ---------------------- -------- --------- -------- -------- ---- -------- MMR 00000000 000000c0 00000000 000000c0 RWIX DARAM0 000000c0 00001f40 00000052 00001eee RWIX [...] ROM 00fe0000 0001ff00 00000000 0001ff00 RWIX
Note that it looks like the ROM is totally unused. Then there is this:
SECTION ALLOCATION MAP (Addresses surrounded by []'s are displayed for convenience only!) output attributes/ section page orgn(bytes) orgn(words) len(bytes) len(words) input sections -------- ---- ----------- ----------- ---------- ---------- -------------- .cinit 0 [ 000000c0 ] 00000060 * 00000029 [...] .text 0 00010000 [ 00008000 ] 00001553 * 00010000 [ 00008000 ] 00000fe7 * hwafft_rom.obj (.text) 00010fe7 [ 000087f3+] 000001fc * c5515.obj (.text) 000111e3 [ 000088f1+] 000000e4 * c5515.obj (.text:retain) 000112c7 [ 00008963+] 000000a6 * main.obj (.text)
...which seems to be saying that the hwafft code is going in .text, which is in SARAM. But finally, there's this:
GLOBAL SYMBOLS: SORTED BY Symbol Address abs. value/ byte addr word addr name --------- --------- ---- 00000001 $TI_capability_requires_rev3 [...] 00ff6cd6 _hwafft_br 00ff6cea _hwafft_8pts 00ff6dd9 _hwafft_16pts 00ff6f2f _hwafft_32pts 00ff7238 _hwafft_64pts 00ff73cd _hwafft_128pts 00ff75de _hwafft_256pts 00ff77dc _hwafft_512pts 00ff7a56 _hwafft_1024pts [...]
Which suggests they are going in ROM? But maybe the linker is just creating meaningless symbols and putting them there?
Compiling the code and running it does actually give me an FFT though, I just don't know where the code is going. The technical note relating to this code doesn't have any build instructions, so I assumed I could just add it to a CCS project. Is that not the right approach?
I made some changes to my setup. I added:
.sect "hwafft" .align 256
...to the top of hwafft_rom.asm, and updated my linker script to put this section in ROM (ie. starting at 0xFE0000). Sure enough, in the output map, the symbols are there and I get no warning. However, when I try to flash the device (I'm using an ezDSP board), Code Composer tells me:
C55xx: Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map.
C55xx: File Loader: Verification failed: Values at address 0xFE0000@PROGRAM do not match Please verify target memory and memory map.
C55xx: GEL: File: /home/[...].out: a data verification error occurred, file load failed.
I thought the ROM was only non-writable from user code on the chip itself. How do I flash code to it?
Okay, I finally figured out that the ROM is not just ROM-from-the-CPU's-perspective, it really is ROM. The HWAFFTs are already programmed in there and won't change. So I don't need the hwafft_rom.asm, it's just in that zip file for reference:
For reference, hwafft_rom.asm is included in SPRABB6.zip and contains the HWAFFT routines exactly as they exist in the ROM of the affected revisions.
So totally removing the hwafft_rom.asm from my project and using the linker-based addresses like before is what I need.