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 CMAXIIBUSEXCEPTION = 1 PARAMETER CMAXIDBUSEXCEPTION = 1 PARAMETER CILLOPCODEEXCEPTION = 1 PARAMETER COPCODE0x0ILLEGAL = 1 PARAMETER CUSESTACKPROTECTION = 1 PARAMETER CUNALIGNEDEXCEPTIONS = 1 PARAMETER CPVR = 2 ~~~

I compiled the BSP in Eclipse activating exceptions:

~~~ PARAMETER MICROBLAZE_EXCEPTIONS = true ~~~

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

~~~

~~~

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 crashinstructions[10]; typedef void (*crashinstructions_t) (void);

crashinstructionst crashinstructionsp;

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

crashinstructionsp = (crashinstructionst) crashinstructions; (*crashinstructions_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, handleotherex_tail; ori r5, r0, 0x7;

handleotherextail:
PUSHREG(7); <<<<< block on this instruction PUSHREG(8);
PUSHREG(9);
PUSHREG(10);
PUSHREG(11);
PUSHREG(12); PUSHREG(15); PUSH_REG(18);
... ~~~

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

What could it be ?

debugasm

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?

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: XEXCIDILLEGAL_OPCODE ~~~

I still can not perform the "Debug" using the same program.

I'll do some more testing.

Thanks very much.

debugasm

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.