Specifications

For more information, refer to the “The Nios II Instruction-Related Exception Handler” chapter for a
description of the instruction-related exception handler and how to register it.
Related Information
The Nios II Instruction-Related Exception Handler on page 8-32
Software Trap Handling on page 8-31
Software Trap Handling
If no instruction-related exception handler is registered, the HAL software exception funnel checks for a
trap instruction. If the exception is caused by a trap instruction, the trap exception handler executes a
break instruction. The break instruction transfers control to a hardware debug core, if one is available. If
the exception is not caused by a trap instruction, it is treated as a miscellaneous exception.
Miscellaneous Exceptions
If the software exception is not caused by an unimplemented instruction or a trap, it is a miscellaneous
exception.
If a debug core is present in the Nios II processor, traps and miscellaneous exceptions are handled
identically, by executing a break instruction.
For more information about the flowchart of the HAL software exception funnel, including the optional
trap logic, refer to the "HAL Software Exception Funnel Including the Optional Instruction Emulation
Logic" figure (Figure 8-2).
If a debug core is present in the Nios II processor, the trap logic is omitted.
In a debugging environment, the processor executes a break, allowing the debugger to take control. In a
nondebugging environment, the processor enters an infinite loop.
For more information about the Nios II processor break instruction, refer to the "Programming Model"
chapter.
For more information about the Nios II processor break instruction, refer to the "Instruction Set
Reference" chapter of the Nios II Processor Reference Handbook.
Miscellaneous exceptions can occur for these reasons:
Advanced exceptions, the memory protection unit (MPU), or the memory management unit (MMU)
are implemented in the Nios II processor core.
You need to include the unimplemented instruction handler.
A peripheral is generating spurious hardware interrupts. This is a symptom of a serious hardware
problem. A peripheral might generate spurious hardware interrupts if it deasserts its interrupt output
before an ISR has explicitly serviced it.
For more information about how to handle advanced and MPU exceptions, refer to the “The Nios II
Instruction-Related Exception Handler” chapter.
For more information about how you need to implement a full-featured operating system to handle
MMU exceptions, refer to the "Programming Model" chapter.
For more information about the unimplemented instruction handler, refer to the “Unimplemented
Instructions” chapter.
Related Information
The Nios II Instruction-Related Exception Handler on page 8-32
Unimplemented Instructions on page 8-29
NII5V2
2015.05.14
Software Trap Handling
8-31
Exception Handling
Altera Corporation
Send Feedback