• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 81 subscribers
  • Views 810 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

F28377d VCU II library cfft_unpack function problem

f D
Prodigy 170 points


My project sometimes couldn't run correctly,either going to illegal interrupt ISR or unenable interrupt ISR. Under this case,the RPC vlaue always point to the return address of the cfft_unpack function. The VCU II library version is V2_00_00_00. Is there something wrong? The code is as follow,


  CFFT_Obj CFFT;
  CFFT_Handle handleCFFT;

  // Step 1: Initialize CFFT object
  CFFT.pInBuffer  = iTIFFTinputbuffer;
  CFFT.pOutBuffer = iTIFFTResultbuffer;

  CFFT.init = (void (*)(void *))CFFT_init64Pt;
  CFFT.run  = (void (*)(void *))CFFT_run64Pt;

  // Step 2: Initialize the handle
  handleCFFT = &CFFT;
  // Step 3: Calling the init() will setup the twiddle factor table
  // and run the Forward FFT followed by an unpacking routine
  CFFT.init(handleCFFT);
  CFFT.run(handleCFFT);
  CFFT_unpack(handleCFFT);

Look foward to your reply. Thank you.

  • 0
    TI__Mastermind 20850 points
    Try the following.

    1. Rebuild the VCU2 library
    2. make sure the .stack section is in the lower 64K of memory (any of the RAMLSx)
    3. there is a v2.10.00.00 try that instead
    4. illegal interrupt usually means the CPU ran into an illegal opcode and that caused a TRAP which goes to the illegal ISR, so
    a. in the project settings make sure -vcu_support=vcu2 (and not vcu0)
    b. take a look at the code in the disassembly window, does it match the assembly in the source files?? if not there was an issue loading or with the
    .lib, if this is the case rebuild the library again.
  • 0 in reply to Vishal_Coelho
    Prodigy 170 points
    Thank you for your reply.
    I check out my project according to your suggestions. In my project,the cfft_unpack function was copyed to RAM to run. On the start,the cfft_unpack function's run place was correct,but runing for a moment,the cfft_unpack function code in the run place RAM was modified.So I think the problem has nothing to do with the cfft_unpack function itself.
    The .stack was enough and arrarys ' boudary was also safe. I don't know what happened during the run process.Please give me some suggestions for this kind of problem.
    Thanks again.
  • 0 in reply to f D
    TI__Mastermind 20850 points

    Ok, First off i would check the linker command file placement; how are you copying the CFFT_unpack from FLASH to RAM?

    Then at runtime check the RAM location in the disassenbly window against the source assembly code. Now if it is getting overwritten you likely have some code somwhere that is perhaps writing past the bounds of an array and overwriting the code. This could also happen if you have insufficient stack space and the stack is directly above the code. You can set a H/W Watchpoint with the address of the unpack routine in RAM. So lets say the unpack function is supposed to run from address 0xA000. You set a H/W watchpoint to watch for writes to location 0xa000. This way you will know if something is corrupting your code

  • 0 in reply to Vishal_Coelho
    Prodigy 170 points
    Very glad to receive your reply.
    My project is still sometimes running to illegal Interrupt ISR. I checked my code carefully,but nothing useful clue to be found. In TI's document "Silicon Errata",there are some suggestions about nested interrupts. In my project the nesting interript code is as below:
    EPwm8Regs.ETCLR.bit.INT = 1;
    TempPIEIER = PieCtrlRegs.PIEIER3.all; PieCtrlRegs.PIEIER3.all &= 0x0040;
    PieCtrlRegs.PIEACK.all = PIEACK_GROUP3; // Enable PIE interrupts
    IER = M_INT3|M_INT1; // Instead of "asm ( "NOP")" EINT;
    .......... DINT;
    PieCtrlRegs.PIEIER3.all = TempPIEIER;
    The code is a little different from the example code. Is there something wrong?
    And Is there some documents about the Reserved Ram Address ,such as Address 0x84a,and so on.Because under abnormal case,the value in the address is the same to the PC resgister 's value.
    Look foward to your reply.Thanks.
  • 0 in reply to f D
    TI__Mastermind 20850 points

    Sounds like you have some missing code, i.e. code that you load to flash but did not copy to RAM. You hit an illegal opcode and that results in the illegal ISR. Its probably the interrupt service routine that you have assigned to a section that is loaded to flash but with a run address in RAM. you will need to memcpy the ISR to RAM at the start of your main(). Either that or you are somehow overwriting that RAM section that contains code.....the usual culprit is stack overflow or array overflow. I would ensure that your code is not getting overwritten once its been placed in RAM.