Microblaze install exception handlers problem …
Posted by
debugasm on 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 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:
~~~
define configINSTALLEXCEPTIONHANDLERS 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 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
Microblaze install exception handlers problem …
Posted by
rtel on 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?
Microblaze install exception handlers problem …
Posted by
debugasm on 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: XEXCIDILLEGAL_OPCODE
~~~
I still can not perform the “Debug” using the same program.
I’ll do some more testing.
Thanks very much.
debugasm
Microblaze install exception handlers problem …
Posted by
rtel on 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.