[MPC5674F] Sporadic IVOR6 / IVOR13 Exceptions Under High CAN Interrupt Load in RTOS Environment

[CNarendra]

Hello NXP Support,

We are working on an application based on the MPC5674F microcontroller using Micrium OS (V3), configured in Software Vector Mode using IVOR4 (External Interrupt).

The system operates reliably under no external interrupt conditions. However, under interrupt load—particularly when all CAN channels are actively receiving via INT. we  encounter the following exceptions:

IVOR6 – illegal address Exception

IVOR13 – Program Exception

To implement the ISR handling, we referred to the MPC574xG Micrium port code, and adapted a similar stack-switching mechanism. Our ISR handler follows the standard pattern:

• Increments the interrupt nesting counter on entry.
• Saves the current task stack pointer into the TCB during the first interrupt.
• Switches to a dedicated ISR stack.
• Restores the task stack and decrements the nesting counter on exit.

Despite this setup, the system crashes sporadically during or shortly after ISR execution.

Observations:
Application crashes with above mentioned Exceptions

The exceptions seem to indicate potential stack corruption, misalignment, or unintended re-entry.

Request:
Are there any known issues, hardware considerations, or subtle ISR handling differences in Software Vector Mode (IVOR4) specific to the MPC5674F compared to MPC57xx devices?
Should we account for any additional alignment, stack integrity, or MSR-related precautions?

Any insights or recommendations would be greatly appreciated to help us root-cause and resolve this issue.

Kindly find attachment's of both MPC5674F and MPC57xx Notes

Thank you,

Narendra C

[lukaszadrapa]

Hi @CNarendra 
Yes, there are some differences: IVOR offsets are different (needs to be initialized on MPC5674F, on MPC5748G the offsets are given), INTC base address is different... But the IVOR4 handler can be the same, there are no differences.
Have you been able to analyze the stack content after the crash? I think this could provide the most valuable details.
Regards,
Lukas

[CNarendra · Accepted solution]

The issue was due to a mismatch between software and hardware configuration — the FPU was enabled in the porting code, but not initialized in the hardware. After correcting this, the Application now runs reliably even under high CAN interrupt load.

-Narendra .C