MPC5746R interrupt immediately after boot in debug

[jamesmurray]

I have a strange issue with an MPC5746R that seems to have started since I censored the device.

I'm using S32DS and a Multilink FX.

I can connect to debug ok and have a breakpoint set at _start.

When flashing code or hitting the "reboot processor" button, I reach that breakpoint.
However, as soon as I hit "step", I get to IVOR4. This then tries to stack the context, but as R1 is uninitialised (zero) it causes an IVOR1 exception.

The only workaround I can think of presently is to use a DCF record to set the IVPR1 to point to a known address that contains RFI.

Where is this interrupt coming from immediately after reset? All of the INTC space is showing zeros.

Any other ideas?

James

[jamesmurray]

Once again trying to post without being logged in loses my post.

As you can see, the code I posted already is mostly your example code for running the PLL.

I'm presently running on MPC5746R-DS while I work on the OTP in case I need to swap a chip.

I don't want to share my project presently. If I get chance I will try to whittle it down to the smallest code required to reproduce this problem.

The only difference between working and not working is enabling censorship (keys, DCFs, lifecycle.)

James

[jamesmurray]

(The above replies seem to be out of order. Confusing.)

I tried disabling all peripherals through their control registers and also disabling all peripheral clocks.

The mode transition still fails.

James

[petervlna]

Hello,

Does the change of target clock to IRC make pass the mode transition?

Do you use progressive clock switching?

Its really hard to tell you where is the issue from the available description.

If you could isolate the issue in code and send it to me I will have a look at it.

Best regards,

Peter

[petervlna]

Hello,

Hmm, try to change target system clock to IRC. This will exclude any HW issue.
Can you try some of our exmaple codes where we run PLL with no issues?
Could you share code (binary file / or whole project), where you demonstrate the issue? I will debug it here to see if I can find something obvious.
Are you running it in NXP EVB or your custom board?

best regards,

Peter

[jamesmurray]

Here's the code:

//Mode transition to enter RUN0 mode:
MC_ME.MCTL.R = 0x40005AF0; //Enter RUN0 Mode & Key
MC_ME.MCTL.R = 0x4000A50F; //Enter RUN0 Mode & Inverted Key
while(MC_ME.GS.B.S_MTRANS){}; //Wait for mode transition to complete  <--------------- stuck here
while(MC_ME.GS.B.S_CURRENT_MODE != 4){}; //Verify RUN0 is the current mode

[petervlna]

Hello,

FCCU NCFSx register reflects the fault latched in FCCU during applicaiton execution.

Have in mind that to read FCCU NCFSx registers you have to executed defined sequence. (writing to OPR bitfiled 0xa)

I just installed an unsecured chip on the eval board and loaded up the exact same firmware. No problem on reboot.

Hmm, which protection do you used?

My next roadblock is a mode transition in the startup code doesn't work.

From which mode to which mode do you make transitions?

Conditions? Most probably some active clock on peripheral is blocking you transition. So incorrectly sad clock modes for target mode.

best regards,

Peter

[jamesmurray]

I came back to this issue again today and I'm getting the same behaviour as reported before.

I haven't configured the FCCU and trying to do anything with it from debug give me an error message:

"Error writing memory block (ExecutionException)"

I tried to write 0x0000,000A to the CTRL

Also trying to write OP1 key to the CTRLK reg, same error message.

> Hmm, which protection do you used?

JTAG key is enabled and I set the chip to "OEM production"

>From which mode to which mode do you make transitions?

MC_ME.GS.B.S_CURRENT_MODE = 4 before and after. This is in the NXP supplied clock config code.

> Most probably some active clock on peripheral is blocking you transition. 

I saw reference to this in the manual but I don't understand how I should resolve it.

What is the best approach? Should I go through each peripheral I am using and set them all to disabled in the peripheral's control register? Or is it better through the registers where each peripheral can be enabled or disabled in a particular run mode?

James

[petervlna]

Hello,

Could you share assembly code and core registers and memory content of executed instruction which cause the issue?

If you skill the instruction in debugger, does the code go to IVOR?

What is the content of FCCU when the issue occurs?

Best regards,

Pete

[jamesmurray]

Here's the current boot sector and beginning of startup code.

------------------------------------

#************************** .boot_header section *****************************
.section .boot, "axv"
.LONG 0x005A0008 # BH conf: Core1 Only - Can boot others via ME
.LONG 0x00000000 # Reserved for future use
.LONG 0x00000000 # Configuration Bits
.LONG 0x00000000 # Configuration Bits
.LONG 0x00000000 # CPU Checker Reset Vector
.LONG _start # CPU1 Reset Vector
.LONG 0x00000000 # CPU0 Reset Vector
.LONG 0x00000000 # Padding

#*****************************************************************************/

.section .text, "avx"

e_nop /* Add padding in case spurious interrupt */
e_nop
e_nop
e_nop

#******************************************************************************
# Function: _start_core1 *
# Content: Initialization of Core1 *
#******************************************************************************
__start:
_start:

#**************************************************
# Disable EE/ME/CE *
# MSR[ME] = 1, others = 0 *
#**************************************************
e_lis r6, 0x0000
e_or2i r6, 0x1000
mtmsr r6

------------------------------------

On reboot in the debugging, the instruction pointer is at

      _start:
->> 00f9e02c: 0x70c0e000 e_lis r6,0
      00f9e030: 0x70c2c000 e_or2i r6,4096

Step (instruction stepping mode):

->> 51000044: 0x780000bc e_b 0x51000100
(This the IVOR4 handler)

Step:

->> 51000100: 0x182106b0 e_stwu r1,-80(r1)

Step:

IVOR1

R1 = 0, so trying to e_stwu indexed to R1 causes an exception.

As a temporary workaround, I wrote some assembler as a "default handler" for the IVORs and manual set IVPR to point to this memory area after boot, now I'm able to trap the IVOR4 exception and read IACKR1 to determine it as an eTPU interrupt. Reading IACKR1 acknowledges that. e_rfi returns to the wrong address (before _start) but execution does continue.

My next roadblock is a mode transition in the startup code doesn't work.
The reference manual makes it clear that mode transitions "must use a timeout" but the crt0_core1.s code from NXP doesn't use one and gets stuck in an infinite loop. From other posts this might be related to peripherals already using IRCOSC or XOSC before the transition.

As a test, I just installed an unsecured chip on the eval board and loaded up the exact same firmware. No problem on reboot.

What did you want me to look for in the FCCU ?

James