Nios II exception handler

[Altera_Forum]

Hi, 

I'm using Nios II and experiencing some strange behaviors. 1. Sometimes the system gets stuck. 2. The system resets. 3. In debug mode - the software get stuck after going to a trap.  The Hardware is Altera's Cyclon3 with Quartus 12 SP2.  In order to better understand the problem I want to try and catch exception with exception handler.  I'v enabled hal.enable_instruction_related_exceptions_api in bsp editor, implemented and registered the handler.  The handler does not work the way I expected it. It is not triggered at all.  How can I test it? Do I need to add something to the hardware as well?  Thanks

[Altera_Forum]

I found out that it is needed to build the hardware with the advanced exception options on. 

In the SOPC builder I checked the following in Advanced features: Exception Checking: 1. Illegal instructions 2. Missaligned memory access. 3. Extra exception information.  After building the new hardware, the handler was triggered when trying to write on missaligned address or trying to execute function from address 0x0. Now I want to try and test trap handling. How can I trigger a trap instruction to be handled with the handler I implemented?

[Altera_Forum]

int x[2]; 

 later: *(int)((char *)x + 1) = 1;

[Altera_Forum]

This code raised only the miss-alignment exception. Not the trap instruction exception. 

 How can I cause this exception?

[sRama28]

hi 

i am using MAX10 FPGA with PHY 88E1111 phy IC for ethenet connection with SRAM memory [4MB].

when running code NIOS is breaking at getting cause value is 5 in debugger . Also sometimes hang in running mode and restarting the NIOS .

Q1. what is the route cause for this issue?

Q2.how to solve these exception ?

Q3.anything i want to change in my BSP settings or QSYS file?

please help me to resolve the issue quickly..

[Altera_Forum]

asm volatile("trap")

[Altera_Forum]

Thanks. It worked. 

Do you know of a way to protect from array overflow? Like the following: int x[2]; x[3] = 1; //I want to protect against this kind of instructions. I'd like to have an exception generated in this case.

[Altera_Forum]

You won't find an easy solution to that one. Some options: 

1) Add software to verify that x[3] doesn't change. 2) Use a mmu and make x[2] be the end of a memory page, and make sure the following page is never allocated. 3) Use on-chip debugger facilities to trap on writes to specific locations (only a few traps will ever be supported, not sure the nios has any). 4) Use signaltap to detect writes to x[3]. 5) Wrap all the array accesses in functions and verifu=y the index. 6) Write the code carefully!