TMS320F28P650SK: cpu falls in ILLEGAL_ISR

Hi,

An "Illegal ISR" (Illegal Operation Trap/ITRAP) on TI C2000 F28x devices indicates the CPU tried to execute an invalid instruction, such as 0x0000 or 0xFFFF. This is often caused by the program counter jumping to an uninitialized or wrong memory address, frequently related to improper interrupt vector table configuration, stack overflow, or memory access issues when switching from RAM to Flash. 

• Uninitialized PIE Vectors: The Peripheral Interrupt Expansion (PIE) table is not properly initialized, causing interrupts to trigger, but the vector points to an invalid address.
• Stack Overflow: The stack grows too large and overflows, overwriting code or data.
• Missing RamFuncs Copy: Functions meant to run from RAM (e.g., flash programming, timing-critical code) were not copied from Flash to RAM at runtime.
• Invalid Memory Access: Accessing a memory address that is not mapped or using wrong page (page 0 vs. page 1).
• Improper _FLASH Definition: When building in FLASH configuration, forgetting to define _FLASH in the project settings can cause incorrect execution.
• Debugger/Hardware Interaction: Sometimes related to the debugger's ability to update the stack pointer during active debugging. 

1. Locate the Error: When the illegal ISR triggers, halt the processor in CCS and check the Program Counter (PC). If the PC points to 0x3FFF or similar, it's often an uninitialized interrupt vector.
2. Inspect the Stack: If the PC points to an address outside of expected code, look at the stack to see what function last called the illegal address.
3. Check .map File: Verify that your linker command file (.cmd) does not have memory overlapping, especially with ramfuncs or stack/heap sections.
4. Verify memcpy: Ensure that memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, &RamfuncsLoadSize); is called before any ramfuncs are executed.
5. Disable Interrupts: Temporarily disable all interrupts (DINT) at the beginning of main() to see if the issue goes away. If it does, the issue is with an unconfigured ISR.
6. Set a Hardware Breakpoint: Put a breakpoint at the ILLEGAL_ISR handler to catch when it enters and look at the call stack.

• Initialize PIE Table: Ensure InitPieVectTable(); is called early in main().
• Initialize Vector Table: Use InitPieCtrl(); and InitPieVectTable(); properly.
• Check Memory Mapping: Ensure that your code is not overwriting key memory regions.
• Use memcpy for Functions: Ensure all functions in the .TI.ramfunc section are copied to RAM.
• Increase Stack Size: If a stack overflow is suspected, increase the stack size in the project properties (linker settings). 

Thanks

Thank you. So, could you please  analyse the possible cause of my question based on your experience？I try different ways, and I think the common causes like stack overflow, uninitialized PIE Vectors, Missing RamFuncs Copy could not happen in my project.

Could you try below steps ?

• Verify Function Pointer Initialization: Ensure svpwm_instance.calc is assigned to the correct function address before the ISR triggers. A null or uninitialized pointer causes ILLEGAL_ISR.
• Check svpwm_instance Lifecycle: Ensure svpwm_instance is a global or static variable and not allocated on a stack that might be cleared or corrupted.
• Debug with Breakpoints: Place a breakpoint at the svpwm_instance.calc line. Step into the call to see if the address being branched to is valid.
• Check Stack Size: The function pointer method might use more stack space, leading to a stack overflow, which can trigger an ILLEGAL_ISR. Increase the stack size.
• Add volatile Keyword: Ensure svpwm_instance is declared as volatile if it is modified elsewhere in the code.

Thanks