MPC5777C IVOR13 Exception

[darq]

Hello,

We occasionally get IVOR13 exception which i do not understand fully. I get that it is supposed to happen when core is trying to access data from an invalid address but i do not understand why it happens in our case. The last address executed before going to exception handling function from call stack is 0xa000ab58 but the address of offending instruction from SRR0 register is 0xA00105DC. From the assembly i can see that it is trying to load data from address 0x40400417 (R6). I am not sure for now where is this address coming from but why is this instruction being executed in the first place when the executed instruction address should be 0xa000ab58. Is there some mechanism in the core that could explain this?

General Registers General Purpose and FPU Register Group
r0 0xa000ab58 (Hex)
r1 0x4005e160 (Hex)
r2 0x40049774 (Hex)
r3 0x17 (Hex)
r4 0x400429d2 (Hex)
r5 0x40400417 (Hex)
r6 0x40400417 (Hex)
r7 0x40042a09 (Hex)
r8 0x8 (Hex)
r9 0x0 (Hex)
r10 0x40041fc8 (Hex)
r11 0x4005e250 (Hex)
r12 0x400005ef (Hex)
r13 0x40049774 (Hex)
r14 0xe0e0e0e (Hex)
r15 0xf0f0f0f (Hex)
r16 0x10101010 (Hex)
r17 0x11111111 (Hex)
r18 0x12121212 (Hex)
r19 0x13131313 (Hex)
r20 0x14141414 (Hex)
r21 0x15151515 (Hex)
r22 0x16161616 (Hex)
r23 0x17171717 (Hex)
r24 0x18181818 (Hex)
r25 0x19191919 (Hex)
r26 0x1a1a1a1a (Hex)
r27 0x1b1b1b1b (Hex)
r28 0x1c1c1c1c (Hex)
r29 0x1d1d1d1d (Hex)
r30 0x1e1e1e1e (Hex)
r31 0x4005e160 (Hex)
pc 0xa0034ff0 <cpu0IsrDataTlbError+8>
msr 0
cr 0x80000008 (Hex)
lr 0xa000ab58 <netServiceHandler+684>
ctr 0xa0009a7c (Hex)
xer 0

SRR0= 0xA00105DC; //SPR 26
SRR1= 0x00008000; //SPR 27
CSRR0= 0x00000000; //SPR 58
CSRR1= 0x00000000; //SPR 59
DEAR= 0x40400417; //SPR 61
ESR= 0x00000020; //SPR 62
IVPR= 0xA0000000; //SPR 63
IVOR0= 0x00000400; //SPR 400
IVOR1= 0x00000410; //SPR 401
IVOR2= 0x00000420; //SPR 402
IVOR3= 0x00000430; //SPR 403
IVOR4= 0x00000440; //SPR 404
IVOR5= 0x00000450; //SPR 405
IVOR6= 0x00000460; //SPR 406
IVOR7= 0x00000470; //SPR 407
IVOR8= 0x00000480; //SPR 408
IVOR9= 0x00000490; //SPR 409
IVOR10= 0x000004A0; //SPR 410
IVOR11= 0x000004B0; //SPR 411
IVOR12= 0x000004C0; //SPR 412
IVOR13= 0x000004D0; //SPR 413
IVOR14= 0x000004E0; //SPR 414
IVOR15= 0x000004F0; //SPR 415
IVOR32= 0x00009D50; //SPR 528
IVOR33= 0x00003FF0; //SPR 529
IVOR34= 0x0000A5F0; //SPR 530
IVOR35= 0x00009ED0; //SPR 531
MCSRR0= 0x00000000; //SPR 570
MCSRR1= 0x00000000; //SPR 571
MCSR= 0x00000000; //SPR 572
MCAR= 0xBB566BE0; //SPR 573
DSRR0= 0x6F8D3FE9; //SPR 574
DSRR1= 0x73D13BD8; //SPR 575

LST_Z7_0_Debug [GDB PEMicro Interface Debugging]
LST_Z7_0.elf
Thread #1 (Suspended : Breakpoint)
cpu0IsrDataTlbError() at Isr.c:386 0xa0034ff0
netServiceHandler() at NetService.c:102 0xa000ab58
netServiceHandler() at NetService.c:102 0xa000ab58
isoTpHandler() at IsoTp.c:523 0xa000a78c
taskIdle() at Tasks.c:119 0xa0033814
0xa0013980
C:\NXP\S32DS_Power_v2.1\eclipse\plugins\com.pemicro.debug.gdbjtag.ppc_2.0.2.202005132054\win32\pegdbserver_power_console
powerpc-eabivle-gdb

a00105aa: se_lwz r6,8(r31)
a00105ac: e_lwz r7,84(r31)
a00105b0: cmpw cr7,r6,r7
a00105b4: mfcr r7
a00105b8: e_rlwinm r7,r7,28,0,3
a00105bc: mtcrf 128,r7
a00105c0: e_bge 0xa00105e6 <didGetData+874>
550 _data[n++] = p[j];
a00105c4: se_lwz r7,8(r31)
a00105c6: e_addi r6,r7,1
a00105ca: se_stw r6,8(r31)
a00105cc: se_mr r6,r7
a00105ce: e_lwz r7,76(r31)
a00105d2: se_add r7,r6
a00105d4: se_lwz r6,20(r31)
a00105d6: se_lwz r5,56(r31)
a00105d8: add r6,r5,r6
a00105dc: se_lbz r6,0(r6)
a00105de: se_extzb r6
a00105e0: se_stb r6,0(r7)

Best regards

[lukaszadrapa]

Hi,

call stack shows only first address of a function. If an error occurs later in a function, SRR0 won't correspond to that address. SRR0 holds the address of instruction which really caused the problem. It looks like there's some problem with this command: _data[n++] = p[j];

As a first step, I would check if 'n' and 'j' are in expected range.

Regards,

Lukas

[darq]

Hi,

Thank you for your answer but i don't think this is the case. When the program execution is stopped by debugger, then the highest position on call stack shows current instruction being executed which is also confirmed by PC register and lower entries in the call stack show addresses from where the function was called. Any other suggestions how this address discrepancy could be explained?

Best regards

[lukaszadrapa]

Hi,

yes but last position shows

cpu0IsrDataTlbError() at Isr.c:386 0xa0034ff0

which corresponds to program counter. This is obviously IVOR13 handler. But this is an exception, this is not called by standard program flow. So, previous position in call stack will not be equal to SRR0. From hardware point of view, SRR0 is important now.

Regards,

Lukas