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.

TMS320F28377D: Regarding FPU library

Part Number: TMS320F28377D

We have been working on TI's FPU library "c28x_fpu_dsp_library"  V1.5 on TMS320F28377 dsp.

Below attached is a picture of library's user guide related to "CFFT_f32" function.

What does the highlighted note means?

  • The note means that the function must complete before being called again. You could not, for example, interrupt the function before it completes, call the function again, and then return to the first call. In such a scenario variables used by the first call would be changed by the second.

    Regards,

    Richard
  • Thanks for your reply.
    While executing this "CFFT_f32" function, before its completion if other interrupts(timer, sci, spi, etc) are called then will it affect output of "CFFT_f32" function?

    Regards,
    Shashank.
  • Only if they call the CFFT_f32 function or modify any of the global variables it uses.  Otherwise there should be no problem.

    Regards,

    Richard

  • What do you mean by global variables?

    As per my knowledge this are the variables are as below.

    typedef struct
    {
    	float32 *InPtr;								  //!< Pointer to the input buffer
    	float32 *OutPtr;							  //!< Pointer to the output buffer
    	float32 *CoefPtr;							  //!< Pointer to the twiddle factors
    	float32 *CurrentInPtr;						  //!< Points to input buffer at each FFT stage
    	float32 *CurrentOutPtr;						  //!< Points to output buffer at each FFT stage
    	uint16_t Stages;							  //!< Number of FFT stages
    	uint16_t FFTSize;							  //!< Size of the FFT (number of complex data points)
    } CFFT_F32_STRUCT;
    
    
    float32 CFFTin1Buff[CFFT_SIZE * 2];
    float32 CFFToutBuff[CFFT_SIZE * 2];
    float32 CFFTmagBuff[CFFT_SIZE];
    float32 CFFTF32Coef[CFFT_SIZE];
    CFFT_F32_STRUCT cfft;
    CFFT_F32_STRUCT_Handle hnd_cfft;

    Are there any other global variables used by CFFT_f32 function?

    We are facing a problem. You can refer this thread for reference

    e2e.ti.com/.../638660

  • The global variable in this case is "cfft". The argument to CFFT_f23() is pointer to that struct and I can see from the assembly code that structure elements, such as input and output buffer pointers, are being modified. The author of this code I no longer with this group, but it seems to me this is the reason for the restriction you first asked about in this thread. As long as your other ISRs are not modifying this structure they should be able to interrupt CFFT_f23 without causing any issue. The same applies to ICFFT_f32 mentioned in your other post.

    I can see someone has been assigned to your other post and should be responding shortly.

    Regards,

    Richard
  • Thank you for your reply.
    The structure that is being provided as input to CFFT_f32() function is not modified in any interrupt but still output of function is affected. If we disable "Timer0" interrupt(interrupt group 1) then no problem is observed.
    If we enable "Timer0" interrupt(interrupt group 1) with its ISR having only its interrupt group acknowledgement(no other code being executed from it), then we face same problem in CFFT_f32() function output.

    Regards,
    Shashank.
  • This feels more like a CPU bandwidth issue. Have you measured the timing (cycle count and frequency) of your FFT interrupt? It would be worth checking. The best way is to set an I/O pin high on entry and low again on exit, then physically measure the timing on an oscilloscope.

    Also, is that interrupt nestable, and is it on the same PIE group as any other active interrupts?

    Regards,

    Richard
  • Actually CFFT_f32()  function is not called based on interrupt, rather its calling is done in background at every 20mSec.

    CFFT_f32()  function execution time :

    180 uSec with all interrupt disabled.

    324 uSec with only timer0 disabled(interrupt group1 enabled).

    We performed three different test logic as below:

    Test 1:

    We kept timer0 interrupt enabled with no code written in ISR as shown below:

    GpioDataRegs.GPESET.bit.GPIO133 = 1;
    
    CpuTimer0Regs.TCR.bit.TIF = 1;		
    PieCtrlRegs.PIEACK.bit.ACK1 = 1;
    
    //Timer0_ISR_rout();
    
    GpioDataRegs.GPECLEAR.bit.GPIO133 = 1;

    But problem still occurred.

    Test 2:

    We tested it with keeping interrupt group1 enabled but disabling timer0 interrupt before calling of CFFT_f32() function as shown below.

    CpuTimer0Regs.TCR.bit.TIE = 0;					  //Timer interrupt disable.
    GpioDataRegs.GPBSET.bit.GPIO45 = 1;
    
    hnd_cfft->InPtr = CFFTin1Buff;
    hnd_cfft->OutPtr = CFFToutBuff;
    CFFT_f32(hnd_cfft);
    
    GpioDataRegs.GPBCLEAR.bit.GPIO45 = 1;
    CpuTimer0Regs.TCR.bit.TIE = 1;

    After this we did not observe problem occurrence.

    Test 3:

    Then we disabled timer0 interrupt and it's clock, and use EPWM10_INT_ISR(group 3) for our purpose of 200 uSec interrupt as below:

    Uint16 Prev_IER = IER;
    
    GpioDataRegs.GPETOGGLE.bit.GPIO133 = 1;
    
    //Timer0_ISR_rout();
    
    EPwm10Regs.ETCLR.bit.INT = 1;
    PieCtrlRegs.PIEACK.bit.ACK3 = 1;
    
    Prev_IER |= IER_GROUP3;
    IER = Prev_IER;

    But problem still occurred.

    This problem has consumed lots of time and its urgent, so kindly provide guidance as soon as possible.

  • Hi ,

    If possible, can you send me a stripped down version of your project, just the FFT and timer ISR but the same memory assignment if possible, so i can replicate it here and take a look at the assembly?

    Also could you try placing the FFT buffers in the lower 64Kw RAM space and running the code again.
  • Thank for your response.

    You can refer attached code of CPU-1 and CPU-2. In which we are facing problem in output of CFFT_f32 function.

    In periodically call of CFFT_f32 function, most time it gives correct magnitude of given 5th and 7th harmonics order.

    but at some random instance it is giving wrong magnitude of 5th and 7th order.

    You can observed it in do_CFFT() function of "C1_N_FFT.c" file as shown below.

    // Note :
    // As per Dummy data x24.ih_5_load should be 2358.74 and
    // x24.ih_7_load should be 1710.125.
    
    if (fft.ph_fftcalc == &fft.r)
    {
    	x24.ih_5_load = mag_buf[5];
    	x24.ih_7_load = mag_buf[7];
    
    	if(x24.ih_5_load < 2300.0)
    	{
    		x24.error++;
    		GpioDataRegs.GPBTOGGLE.bit.GPIO55 = 1;
    	}
    }

    AHF_3800_DUAL_CPU.rar

  • Hi Shashank,

    I ran your code and the execution does not stop in the error block (for the 5th and 7th bin)

    Amtech said:
    if(x24.ih_5_load < 2300.0) { x24.error++; GpioDataRegs.GPBTOGGLE.bit.GPIO55 = 1; }

    Neither do i see an issue in the IFFT, i dont come across the dead spot, here is a snapshot of my CCS

    I am running only 1 core. Can you turn off the second core and try to run it again to see if the issue persists. 

  • I also just tried the dual CPU mode and im not seeing any dead time in the output of the IFFT. I am setting a breakpoint after the IFFT so it does halt on each go around so i can see the graph.

    Also the execution never stops in the error block (5th and 7th bin issue).

    I am using CGT 16.9.6.LTS, can you try with the latest codegen and see if the issue persists.
  • Thanks for your reply.
    Sorry for my late reply as i was on official leave.
    We are using C2000_CGT 6.4.10. And we are facing problem in same code which we had shared with you.
    Did you check it with continuously for 3-4 hours? Because we are not getting problem continuously.
    We will check with c2000 CGT 16.9.6.LTS. Can you check it with C2000_CGT 6.4.10?
    Regards,
    Shashank
  • We have checked code which we shared with you with "c2000 CGT 16.9.6.LTS", and we didn't face any issues.

    What is the difference in versions "c2000 CGT 16.9.6.LTS" and "C2000_CGT 6.4.10"?

    Is it that this library "c28x_fpu_dsp_library" V1.5 isn't properly supported by older versions like "C2000_CGT 6.4.10", because we didn't find any such note within library's documentation.

    Can you check code with version "C2000_CGT 6.4.10"?


    Regards,

    Shashank.

  • Is there any update regarding this issue?
  • Shashank,

    There is a note in the user's guide for version 1.5 of the library that it requires CGT v6.4.4 or later, so it should have run on 6.4.10 without issue. The library has not been re-tested with later tools, however it is possible that one bug fix generated an unseen issue which was then fixed in a later CGT version.

    There have been 14 major and one critical bug fixes between compiler versions 6.4.10 and 16.9.0.LTS. There was no report specifically relating to the DSP library so I regret I cannot account for which one resulted in the error you are seeing. I think at this stage the best path is simply to update to the latest tools.

    Regards,

    Richard