• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 82 subscribers
  • Views 1664 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.

F28335 ILLEGAL_ISR

Sergio4668
Prodigy 170 points

Other Parts Discussed in Thread: TMS320F28335

Hello TI,
 
I am working on an custom application based on the TMS320F28335. My program runs from flash correctly. But when I included in my project a new source file the processor falls in an ILLEGAL_ISR. This is very confusing to me, since I don´t even call a function from the new code. My new code is as follows:
.
.
.
//
  if(calc_crc==1)
  {
   if(CRC16_RAM()==1)
   {
    calc_crc=0;
   }
  }
  //

Variable calc_crc is always equal to zero (=0), so that, the function is not being called. I try to do what  suggested in http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/p/21640/83625.aspx#83625 increasing the stack size (I doubled it from 0x400 to 0x800), but the problem remains.

Please, could anybody help me to fixed this issue or understand it?

Thank you in advanced.

Sergio

  • 0
    TI__Expert 6475 points

    Sergio,

    I don't have the answer to your question, but I can tell you where to look for help.

    In the F2800 peripheral examples the ILLEGAL_ISR() is the default Interupt Service Routine for the the Illegal Instruction Trap.
    It's documented in the the F2800 CPU manual spru430e at page 322, paragraph 3.6.

    Any one of the following events causes an illegal-instruction trap:

    -  An invalid instruction is decoded (this includes invalid addressing modes).
    -  The opcode value 000016 is decoded. This opcode corresponds to the
    ITRAP0 instruction.
    -  The opcode value FFFF16 is decoded. This opcode corresponds to the
    ITRAP1 instruction.
    -  A 32-bit operation attempts to use the @SP register addressing mode.
    - Address mode setting AMODE=1 and PAGE0=1

    As part of its operation, the illegal-instruction trap saves the
    return address on the stack. Thus, you can detect the offending address by
    examining this saved value.

    The "return address" maybe won't be exactly the one that generated the error, due to the pipeline. But should be very close to it.

    The most frequent cause for this error is the first one: bad addressing mode. You might have an access to a reserved memory location.
    Start checking the memory map and the pointers. You're calculating a CRC, maybe one pointer is not well initialized.

    Hope it helps

    Massimo