Demo sdhc_fatfs_mpc5748g error

[jeromeli]

Hi there,

We try to run the sdhc_fatfs_mpc5748g demo which is included in "S32_SDK_MPC574xx_EAR_0.8.1" on our EVB (MPC574XG-MB + MPC574XG-176DS), but get error message as below:

What should we do to make it run?

[martin_kovar]

Hello,

could you please write me content of MCSRR0 register while you are in IVOR1 exception? This could help us to identify, which instruction caused the IVOR exception.

Regards,

Martin

[jeromeli]

Hello Martin,

I don't know where to find the MCSRR0 register. If it is among the general registers, here are the register values when IVOR1 exception occurs:

r0 16804154
r1 1073814928
r2 1073809716
r3 260
r4 4102
r5 -256252
r6 1
r7 -1507328
r8 0
r9 0
r10 0
r11 1073814992
r12 0
r13 1073809700
r14 0
r15 0
r16 0
r17 0
r18 0
r19 0
r20 0
r21 0
r22 0
r23 0
r24 0
r25 0
r26 0
r27 0
r28 0
r29 0
r30 0
r31 1073814928
pc 0x1002bcc <IVOR1_Handler>
msr 0
cr 572522498
lr 0x10042b8 <InitializeUART+68>
ctr 0
xer 536870912

[jamesmurray]

You can find MCSRR0 in the Special Purpose Registers.

Window -> Show View -> Other -> SPR registers.

However, from the regs above, the Link Register (LR) is likely giving the needed information. Can you post the disassembly (with full opcodes) for a few rows before and after address 0x10042b8.

James

[jeromeli]

MCSRR0 value as follows:

I don't know why the Disassembly window shows nothing:

But I can tell address 0x10041bc is within function LINFlexD_2_Init whose base address is 0x10041a0:

So the address offset from LINFlexD_2_Init is 0x10041bc - 0x10041a0 = 0x1c. I disassemble uart.c and get:

If I didn't go wrong, 0x10041bc should be "se_stw  r6,0(r7)"

[jamesmurray]

I've had the problem where the Disassembly stops working numerous times. What I do to fix it, is to use the X to close that sub-window and then go back to Window -> Show View -> Disassembly to re-open it.

Assuming you've found the relevant address, that's storing the value of r6 (which is 1) into the address pointed to by r7.

r7 was just set to 0xffe90000. That is the address of LINFlexD_2_LINCR1 (from page 1891 for MPC5748G RM) so that looks ok to me? (The problem I had was that the supplier header file pointed to reserved addresses causing a crash.)

Probably best to set a breakpoint at the start of that function and single-step to see exactly where it is bombing out.

The lines at 0xc and 0x12 aren't complete in that disassembly because they haven't been linked yet.

James

[jeromeli]

Yes, now I can see the assemble codes after re-opening the Disassembly window. The last line before going to IVOR1 is as follows:

I've still got no idea of why the exception occurs.

[jamesmurray]

Sometimes the indication here can be misleading. Earlier I said "LR=0x10042b8" so look there... well that's what the disassembly window is doing, but that's the wrong place. (It is the return address where the code would go _after_ LINFlexD_2_Init had completed.)

What you had earlier with "LINFlexD_2_Init is 0x10041bc - 0x10041a0 = 0x1c." is the correct place to be looking.

Put a breakpoint just before the call (e.g. line 130 "fifostate = FIFO_ENABLED"), re-run the code and when the breakpoint hits, step into LinFlexD_2_Init and keep stepping until it goes wrong.

James

[jeromeli]

I installed the brand new release of S32DS (2007 R1), and found that this problem disappeared in the new version. I think we can close this topic now. Thank you! lol

[jeromeli]

I did exactly what you said, the interesting thing was that when I ran it step by step, it didn't go to exception anymore. It executed the whole LINFlexD_2_Init function without any mistake. Then I let it run freely again, and it finally stopped at DevAssert, see as below. Totally beyond my understanding :smileysilly:

[jamesmurray]

I don't know if it is related, but are the Linflex register definitions correct?

Perhaps similar to this?

https://community.nxp.com/thread/463193 

James

[martin_kovar]

Hello James,

I do not think so (but I am not 100% sure ;-)). I have tested this example using Lauterbach debugger and it worked correct on my side. So, I think this could be some PEMicro related problem or something like that. This is the reason I would like to know, which instruction causes IVOR1 exception.

Regards,

Martin

[jeromeli]

Can anyone help?