TMS320F28377D: FFT using Real only input sample data

Hello Ian,

I'll work with you to try and resolve these issues. There are many questions, so you'll have to give me a day or two to review your questions and reply.

On the CCS and MISRA point, I'd like a screenshot of what you are seeing. In the C2000 team here, we use LDRA testbed as well as Klocwork for Static code analysis, including MISRA-C compliance. This helps us identify rules that we are not in compliance with, and accordingly take action. LDRA testbed is expensive from a licensing perspective; Klocwork is better from that standpoint.

Also, another thing we'd like you to consider is switching to the FPU for your FFT needs. The VCU only gives you 16-bit fixed point resolution, whereas with the FPU you get 32-bit floating point resolution (And double precision 64-bit floating point with future devices). Additionally, the VCU will soon lose support for FFT, Viterbi decoding etc., and only CRC will remain. This would affect newer devices, not existing and legacy devices. Just something to think about.

Thanks,
Sira

Sira,
Thanks for getting back to me.
My input data is from a 12-bit ADC so, in principle, 16-bit integer data is OK. However, I'm open to switching to the FPU if you can point me at the relevant resources (docs, example code, etc.).
I've got this far with help from TI Customer Support who were excellent up to the point where my questions became more detailed. The upshot of this is that, if I do switch to FPU, I only now have a couple of days left to successfully implement it ... so don't go away :o)
I'm in your hands ...

Kind regards,
Ian

Sira,

As requested, I have pasted some of the MISRA violations below.

They are taken from my "fft.c" file using code from the "main.c" file in the TI example code.

>> The following warnings at lines 99, 102 and 105 of my fft.c file relate to the following statements in main.c in the TI example:
int16_t buffer1Q15[2u*NSAMPLES]          = {
        #include "data_input.h"
};
int16_t goldenOutputQ15[2u*NSAMPLES]     = {
        #include "data_output.h"
};
int16_t goldenfftOutputQ15[2u*NSAMPLES]  = {
        #include "data_input.h"
};

"../util/fft.c", line 99: warning #1425-D: (MISRA-C:2004 19.1/A) #include statements in a file should only be preceded by other preprocessor directives or comments

"..\util\data_input.h", line 269: warning #1504-D: (MISRA-C:2004 19.15/R) Precautions shall be taken in order to prevent the contents of a header file being included twice

"../util/fft.c", line 102: warning #1425-D: (MISRA-C:2004 19.1/A) #include statements in a file should only be preceded by other preprocessor directives or comments

"..\util\data_output.h", line 269: warning #1504-D: (MISRA-C:2004 19.15/R) Precautions shall be taken in order to prevent the contents of a header file being included twice

"../util/fft.c", line 105: warning #1425-D: (MISRA-C:2004 19.1/A) #include statements in a file should only be preceded by other preprocessor directives or comments

"..\util\data_input.h", line 269: warning #1504-D: (MISRA-C:2004 19.15/R) Precautions shall be taken in order to prevent the contents of a header file being included twice

>> The following warnings at line 771 of my fft.c file relate to the following statement in main.c in the TI example:
>> statement: CFFT.init = (void (*)(void *))CFFT_init1024Pt;
"../util/fft.c", line 721: warning #1472-D: (MISRA-C:2004 16.3/R) Identifiers shall be given for all of the parameters in a function prototype declaration

"../util/fft.c", line 721: warning #1422-D: (MISRA-C:2004 16.9/R) A function identifier shall only be used with either a preceding &, or with a parenthesised parameter list, which may be empty (function "CFFT_init1024Pt")

"../util/fft.c", line 721: warning #1398-D: (MISRA-C:2004 11.1/R) Conversions shall not be performed between a pointer to a function and any type other than an integral type

"../util/fft.c", line 721: warning #515-D: a value of type "void (*)(void *)" cannot be assigned to an entity of type "void (*)(void)"

>> The following warnings at line 772 of my fft.c file relate to the following statement in main.c in the TI example:
>> statement: CFFT.run  = (void (*)(void *))CFFT_run1024Pt;
"../util/fft.c", line 722: warning #1472-D: (MISRA-C:2004 16.3/R) Identifiers shall be given for all of the parameters in a function prototype declaration

"../util/fft.c", line 722: warning #1422-D: (MISRA-C:2004 16.9/R) A function identifier shall only be used with either a preceding &, or with a parenthesised parameter list, which may be empty (function "CFFT_run1024Pt")

"../util/fft.c", line 722: warning #1398-D: (MISRA-C:2004 11.1/R) Conversions shall not be performed between a pointer to a function and any type other than an integral type

"../util/fft.c", line 722: warning #515-D: a value of type "void (*)(void *)" cannot be assigned to an entity of type "void (*)(void)"

Do you have answer yet to my main question?

Kind regards,

Ian

Ian,

Since you are flexible with moving to the FPU, here is what I would suggest.

Please run the FFT examples in the FPU library, located at C:\ti\c2000\C2000Ware_1_00_06_00\libraries\dsp\FPU\c28\examples\fft, and if required, refer to the user guide at C:\ti\c2000\C2000Ware_1_00_06_00\libraries\dsp\FPU\c28\docs

Examples of use to you might be 2837x_rfft_adc, 2837x_rfft_adc_rt and 2837x_rfft. First run them as is on the ControlCARD, ensure they pass, and then adapt them to your specific need and project. I have run all these examples and they pass. For the ADC one, I would use a signal generator sinusoidal input to test functionality. Twiddle factor tables are used if the Macro USE_TABLES is defined, else the table computation is done through a function call. Tables can only support upto a maximum FFT SIZE, 1024 if I remember correctly. Beyond that, you have to
run the twiddle computation function.

Main.c in these examples has a text description at the top that is pretty good. The user guide can supplement to this (we have a JIRA issue to improve the user guide).

Please keep me posted, and I will actively support.

On the MISRA-C, more than the actual violations, I was interested in knowing how you got CCS to report the violations. Did you use some plug in? Can you let me know the steps, and also send a screenshot of the CCS window showing this?

Thanks!
Sira

Sira,

Thanks for your reply. I shall try the FPU implementation this morning and let you know the result.

With regard to showing MISRA violations, the CCS8 install was from the TI CCS download (version 8.1.0.00011), so nothing too exotic there.

The MISRA settings were made in Project  Properties (CCS Build -> C2000 Compiler -> Advanced Options -> MISRA-C:2004), with any violations appearing in the Console panel (along with any other errors or warnings) at the end of building the project. No plugs-ins were required.

My specific settings are below:

I hope this helps.

Kind regards,

Ian

Sira,

I am using the example that you suggested previously with no modifications, and have a couple of initial questions:
1. When I make my first build I get the following reported in the Console panel, which includes an error:
~~~~~~~~~~~~ START ~~~~~~~~~~~~~~
C28xx_CPU1: GEL Output:
Memory Map Initialization Complete
C28xx_CPU1: Error occurred during flash operation: Unknown property "FlashCoreSelection"
C28xx_CPU1: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code. Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.
~~~~~~~~~~~~ END ~~~~~~~~~~~~~~~
Do you see a similar error?
(My platform is LAUNCHPADXL-F28379D)

2. In main.c I see that the header file "math.h" is included. All I'm trying to do at the moment is a proof of concept for work to follow on. However, that later work will be for aerospace use, and that means we shall need to have access to all source code, including the math library. Will this be possible?

Kind regards,
Ian

Ian,

Thanks for the info on MISRA-C checks within CCS.

1. I used the same launchpad as you, built the FLASH_FASTRTS build configuration of the 2837x_RFFT project, launched the target configuration (which should also mention the F28379D device, not F28379S), right-clicked on C28xx_CPU1 (only), selected "Connect Target", then clicked Run-Load Program, navigated to the location of the .out file, and that did the trick. The Flash was programmed, and the code stopped in main().

The project includes the F2837xD_FPU_RFFT_lnk.cmd file. Usually I use the RAM build configuration while debugging, but I switched to the Flash configuration since I saw your messages about Flash Erase. Also, I didn't have to change any Boot Mode settings on the LaunchPad, but I presume that is worth checking as well. However, I just tried loading the RAM build configuration, and that worked too, without any changes. Still, worth looking at the FAQ. (C:\ti\c2000\C2000Ware_1_00_06_00\boards\LaunchPads\LAUNCHXL_F28379D\R2.0\documentation)

2. You'll see our example project includes 2 or 3 libraries (3 if the FPUFastRTS build configuration is chosen). The 2 are rts2800_fpu32.lib and c28x_fpu_dsp_library.lib. Source is available for the latter. The former is supplied by the CCS installation, so I don't have control over that. I presume they are mostly standard C libraries, but possibly some math functions are optimized for the C28 device. The FPUFastRTS library source is available as well (these are select math functions that overlap with the rts2800_fpu32.lib but run faster, at the expense of accuracy).

Thanks,
Sira