Microblaze install exception handlers problem ...

debugasm wrote on Thursday, October 20, 2016:

I’m using freeRTOS for a quick test. I’m going to use the functionality
of “EXCEPTION_HANDLERS” on Microblaze CPU.

I created the MicroBlaze CPU with these settings for “exceptions”:

PARAMETER C_M_AXI_I_BUS_EXCEPTION = 1
PARAMETER C_M_AXI_D_BUS_EXCEPTION = 1
PARAMETER C_ILL_OPCODE_EXCEPTION = 1
PARAMETER C_OPCODE_0x0_ILLEGAL = 1
PARAMETER C_USE_STACK_PROTECTION = 1
PARAMETER C_UNALIGNED_EXCEPTIONS = 1
PARAMETER C_PVR = 2

I compiled the BSP in Eclipse activating exceptions:

PARAMETER MICROBLAZE_EXCEPTIONS = true

In “FreeRTOSConfig.h” I have activate installation of exception handling:

#define configINSTALL_EXCEPTION_HANDLERS 1

The compilation is successful.

The system works, I blink two LEDs with two separate tasks, using a
third task where the serial run I try to start a routine that triggers
an exception:

...
unsigned crash_instructions[10];
typedef void (*crash_instructions_t) (void);

crash_instructions_t crash_instructions_p;

crash_instructions[0] = 0;
crash_instructions[1] = 1;
crash_instructions[2] = 2;
crash_instructions[3] = 3;

crash_instructions_p = (crash_instructions_t) crash_instructions;
(*crash_instructions_p)();
...

I put a breakpoint at 0x20 “vectorhwexception” and one on the
“vPortExceptionHandle” function.

Once I triggered the exception I have the first break at 0x20
“vectorhwexception”, but once again given the “run” the
“VPortExceptionHandle” function is never called, and debugging ends.

Performing “vectorhwexception” step by step, I notice that the execution
is always crashes here:

		...
        ori     r6, r0, 7;
        cmp     r6, r5, r6;
        bgti    r6, handle_other_ex_tail;
        ori     r5, r0, 0x7; 
                
handle_other_ex_tail:       
        PUSH_REG(7);			<<<<< block on this instruction
        PUSH_REG(8);             
        PUSH_REG(9);              
        PUSH_REG(10);             
        PUSH_REG(11);             
        PUSH_REG(12);
        PUSH_REG(15);
        PUSH_REG(18);        
		...

I had a look to the example supplied with freeRTOS: “MicroBlaze_Kintex7_EthernetLite”
but not well-known differences, excluding exception of FP and DIV.

What could it be ?

debugasm

rtel wrote on Thursday, October 20, 2016:

I’m afraid this is a little detailed as the device is so configurable,
so my comments here are suggestions to look for, rather than absolutes.

The instruction you say is causing the issue is pushing a register so:

If a separate exception stack is being used (can’t recall without
digging out the hardware manual), is the stack defined and set up correctly?

If certain stack alignment is required, could it be that the alignment
is not being maintained, and the exception is itself causing an exception?

debugasm wrote on Friday, October 21, 2016:

Hi,

I followed the hardware configuration proposed in freeRTOS package v9.0.0 for inquiries concerning the “MicroBlaze”.

However I tried to compile the software in “Release” mode, start “Run” and the exception is now being captured.

Hardware Exception:

Task Name: Uart

Registers that were stacked prior to this function being called:

R3:  0x82084414
R4:  0x00000001
R5:  0x00000001
R6:  0x0000000A
R7:  0x00000000
R8:  0x00000001
R9:  0x00000003
R10: 0x00000000
R11: 0x00000000
R12: 0x00000000
R15: 0x8006E1B8 (return address from subroutine)
R18: 0xFFFFFFFE
R19: 0x82088554
MSR: 0x000006A2

The value of all other registers:

R2:  0x8008A9C0 (small data area)
R13: 0x8008E730 (read write small data area)
R14: 0x8003FA80 (return address from interrupt)
R16: 0xA5A5A5A5 (return address from trap)
R17: 0x82084418 (return address from exceptions)
R20: 0xA5A5A5A5
R21: 0xA5A5A5A5
R22: 0x00000000
R23: 0x00000002
R24: 0x00000300
R25: 0x00000030
R26: 0x8208454C
R27: 0x82088554
R28: 0xA5A5A5A5
R29: 0xA5A5A5A5
R30: 0xA5A5A5A5
R31: 0xA5A5A5A5
R1:  0x820843F8 (stack pointer)
EAR: 0x00000000
ESR: 0x00000002
EDR: 0x00000000
PC:  0x82084414
FSR: 0x00000000

Exception cause: XEXC_ID_ILLEGAL_OPCODE

I still can not perform the “Debug” using the same program.

I’ll do some more testing.

Thanks very much.

debugasm

rtel wrote on Friday, October 21, 2016:

The return address is being set to 0xa5a5a5a5, which is the value the stack is filled with when the task is created. So it appears the program counter was loaded with a value from the stack when the stack was corrupt.