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.

TMS320C5515: How do I use the HWAFFT (hardware FFT coprocessor) code?

Part Number: TMS320C5515

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?

  • Those warnings seem to be because the HWAFFT functions are being placed in .text and not ROM after all. So any help on how to actually place these functions in ROM like the user guide suggests would be welcome.
  • Hi Jason,

    The listed above warning messages ".. #10188-D: symbol ..." are caused by that this symbols are defined at two places. That could mean that you are including two different header files or libraries or that there is a file that incorrectly defines this symbol. Try to comment one of definitions.

    Regards,
    Tsvetolin Shulev
  • 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.