• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 693 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/TMS320F28069: What could cause a 28069 'Illegal ISR' STOP using XDS220-ISO debugger while debugging code with a UART (RS232) port code.

Keith Abell
Intellectual 420 points
Part Number: TMS320F28069
Other Parts Discussed in Thread: C2000WARE

Tool/software: Code Composer Studio

After I start the debug session and my code has been downloaded into the 28069 and a Putty session tied to COM1 of my laptop and I start running the code I almost immediately end up in the illegal ISR trap.  Any ideas on how to figure out what is causing the Illegal ISR trap?  I am using CCS 8.3 and the 18.12.3.LTS compiler.  Please Help.

Regards,

Keith

  • 0
    TI__Guru* 77460 points

    Keith,

    When the C28x core executes and ILLEGAL opcode, it will save register information, including the PC(program counter) to the stack.  If you are halted in the ILLEGAL ISR, you should be able to:

    1)Use the SP(Stack Pointer) to determine the current location of the stack.

    2)open up a memory window to the location.

    3)If the SP is odd, look at the SP-1(16 bit MSB of address) and SP-2(16 bit LSB of address) for the return address.  Since this is the return address, this -1 word should point to the instruction that caused the ILLEGAL ISR

    4)If the SP is even look a the SP-2 and SP-3 words, and then the same as the above for decoding this.

    Are you saying this only happens when you attempt to initiate comms with the UART?  If so I'd check to make sure that the SCI ISR has been defined both code and vector wise.  The default_ISR that is included with our C2000Ware examples takes care of putting a dummy handler in case the ISR gets called; the non_BIOS.cmd file will handle the vector creation.

    Best,
    Matthew

  • 0 in reply to MatthewPate
    Intellectual 420 points

    Matthew,

    Many thanks for your timely response.  You've given me some handy input in resolving issues of this nature in the future.  Some additional background and what turned out to be a solution found by a simple shut-gun approach.

    I was working with a code base we have used with many of our smart UPS systems and the UART ISR's have been thoroughly wrung  out and tested.  We have a code structure that uses a set of configuration files, one for each system that defines a variety of operational parameters using common core control code.  One of the configuration settings involves management of a UART comm port that can be used for SNMP poling or RS232 ASCII operational information and a configuration file can set the default for SNMP or USER.  I discovered that the port was defaulted for SNMP (which requires its own protocol) and when I switched the default to USER, the illegal ISR trap went away and eliminated the need to drill down via the stack as to what caused the error.  In the interest of time getting a new UPS packaged up for production testing I don't have the time to research it further but I will at some later point, reset the code for SNMP and see how the code gets so confused.

    But I am now armed with some excellent debug information that will assist debug efforts in the future.  Kudos!

    Regards,

    Keith Abell