I am having an issue where a mode switch is causing the processor to reset. The odd thing is that with the debugger attached and a breakpoint after the transition the processor does not reset. See Code below, which was generated with the "MPC574xR_Clock_Calculator_Rev3" excel doc. I also don't find any relevant info in the exception registers? Is there another place to look for clock configuration faults/errors?
//Enable XOSC, PLL0, PLL1, and enter RUN0 with PLL1_PHI as the system clock (200 MHz).
void Sysclk_Init(void)
{
MC_CGM.AC3_SC.R = 0x01000000; //Connect XOSC to the PLL0 input.
MC_CGM.AC4_SC.R = 0x03000000; //Connect PLL0_PHI1 to the PLL1 input.
MC_ME.RUN_PC[0].B.DRUN = 1;
MC_ME.RUN_PC[0].B.RUN0 = 1;
//Enable external oscilator
MC_ME.DRUN_MC.B.XOSCON = 1;
// Set PLL0 as system clock
MC_ME.DRUN_MC.R = 0x00130071;
PLLDIG.PLL0DV.R = 0x50022028; //PREDIV = 2, MFD = 40, RFDPHI = 2, RFDPHI1 = 10
//Mode transition to enter RUN0 mode:
MC_ME.MCTL.R = 0x30005AF0; //Enter RUN0 Mode & Key
MC_ME.MCTL.R = 0x3000A50F; //Enter RUN0 Mode & Inverted Key
while(!MC_ME.GS.B.S_XOSC); //ME_GS Wait for PLL stabilization.
while(!MC_ME.GS.B.S_PLL0); //ME_GS Wait for PLL stabilization.
while(MC_ME.GS.B.S_MTRANS){}; //Wait for mode transition to complete
while(MC_ME.GS.B.S_CURRENT_MODE != 3){}; //Verify RUN0 is the current mode
//Set PLL0 to 400 MHz with 20 MHz XOSC reference.
PLLDIG.PLL0DV.R = 0x50012028; //PREDIV = 2, MFD = 40, RFDPHI = 1, RFDPHI1 = 10
MC_ME.RUN_MC[0].R = 0x001300F4;
//Set PLL1 to 200 MHz with 40 MHz PLL0_PHI1 input.
PLLDIG.PLL1DV.R = 0x00020014; //MFG = 20, RFDPHI = 2
PLLDIG.PLL1FD.R = 0x00000000; //Disable PLL1 fractional divider.
//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
//Reset occurs after this line, but does not reset if debuggin and breakpoint on next line
while(!MC_ME.GS.B.S_XOSC); //ME_GS Wait for PLL stabilization.
while(!MC_ME.GS.B.S_PLL0); //ME_GS Wait for PLL stabilization.
while(!MC_ME.GS.B.S_PLL1); //ME_GS Wait for PLL stabilization.
while(MC_ME.GS.B.S_MTRANS){}; //Wait for mode transition to complete
while(MC_ME.GS.B.S_CURRENT_MODE != 4){}; //Verify RUN0 is the current mode
// Reset occurs before the call to InitPeriClkGen()
InitPeriClkGen();
}
void InitPeriClkGen(void)
{
//SYS_CLK is 200 MHz.
MC_CGM.SC_DC[0].R = 0x80000000; //CHKR_CLK, COMP_CLK, FXBAR_CLK, BD_CLK at system clock divided by 1 (200 MHz).
MC_CGM.SC_DC[1].R = 0x80010000; //SXBAR_CLK and LINCLK (synchronous) at system clock divided by 2 (100 MHz).
MC_CGM.SC_DC[2].R = 0x80030000; //PBRIDGE_x_CLK at system clock divided by 4 (50 MHz).
MC_CGM.AC0_SC.R = 0x02000000; //Select PLL0_PHI as source of Auxiliary Clock 0
MC_CGM.AC0_DC0.R = 0x80040000; //PER_CLK: Enabled at Auxiliary Clock 0 divided by 5 (80 MHz).
MC_CGM.AC0_DC1.R = 0x80070000; //SD_CLK: Enabled at Auxiliary Clock 0 divided by 8 (50 MHz).
MC_CGM.AC0_DC2.R = 0x80040000; //SAR_CLK: Enabled at Auxiliary Clock 0 divided by 5 (80 MHz).
MC_CGM.AC0_DC3.R = 0x80040000; //DSPI_CLK0: Enabled at Auxiliary Clock 0 divided by
MC_CGM.AC0_DC4.R = 0x80040000; //DSPI_CLK1 and LINCLK (asynchronous): Enabled at Auxiliary Clock 0 divided by 5 (80 MHz).
MC_CGM.AC1_SC.R = 0x01000000; //Select XOSC as source of Auxiliary Clock 1
MC_CGM.AC1_DC0.R = 0x80000000; //RF_REF: Enabled at Auxiliary Clock 1 divided by 1 (20 MHz).
MC_CGM.AC2_SC.R = 0x02000000; //Select PLL0_PHI as source of Auxiliary Clock 2
MC_CGM.AC2_DC0.R = 0x80070000; //SENT_CLK: Enabled at Auxiliary Clock 2 divided by 8 (50 MHz).
//PLL0 and PLL1 are configured in SysClk_Init function.
MC_CGM.AC5_SC.R = 0x02000000; //Select PLL0_PHI as source of Auxiliary Clock 5
MC_CGM.AC5_DC0.R = 0x80030000; //eTPU_CLK: Enabled at Auxiliary Clock 5 divided by4 (100 MHz).
MC_CGM.AC5_DC1.R = 0x80030000; //eMIOS_CLK: Enabled at Auxiliary Clock 5 divided by 4 (100 MHz).
MC_CGM.AC6_SC.R = 0x02000000; //Select PLL0_PHI as source of Auxiliary Clock 6
MC_CGM.AC6_DC0.R = 0x00130000; //CLKOUT: Disabled.
MC_CGM.AC8_SC.R = 0x01000000; //Select XOSC as source of Auxiliary Clock 8
MC_CGM.AC8_DC0.R = 0x80000000; //CAN_CLK: Enabled at Auxiliary Clock 8 divided by 1 (20 MHz).
MC_CGM.AC9_SC.R = 0x01000000; //Select XOSCas source of Auxiliary Clock 9
MC_CGM.AC9_DC0.R = 0x80000000; //RTI_CLK: Enabled at Auxiliary Clock 9 divided by 1 (20 MHz).
MC_CGM.AC10_SC.R = 0x00000000; //Select IRCOSC as source of Auxiliary Clock 10
MC_CGM.AC10_DC0.R = 0x000F0000; //FEC clocks: Disabled.
}
I also had a same problem trying to put it to 100Mhz, I solved it by putting this part at the end of the InitPeriClkGen and not at the beginning
//SYS_CLK is 200 MHz.
MC_CGM.SC_DC[0].R = 0x80000000; //CHKR_CLK, COMP_CLK, FXBAR_CLK, BD_CLK at system clock divided by 1 (200 MHz).
MC_CGM.SC_DC[1].R = 0x80010000; //SXBAR_CLK and LINCLK (synchronous) at system clock divided by 2 (100 MHz).
MC_CGM.SC_DC[2].R = 0x80030000; //PBRIDGE_x_CLK at system clock divided by 4 (50 MHz).
If it helps you comment on it to know if it's just my problem or also yours
Without looking at the code and the CPU type...
We had exaclty the same problem with an MPC5777c CPU. It turned out that we need to use the progressive clock switch. Switching the CPU from the slow startup clock to high speed required more current than the power supply was able to handle. Using the prgressive clock switch reduces the power spikes.
Regards
Norbert
I'm very late to the party on this, but posting for future info - progressive clock switch is very beneficial. There are NXP videos about this that show the exact problem where you can get a big voltage dip on the core supply (e.g. 1.25V drops to 1.17V) that causes a LVD reset.
I had the same issue on one board. Enabling the progressive clock switching resolved the problems.
James
Can you elaborate on what you mean by by progressive clock switch? The code I have first switches to the XOSC and and PLL0, it then switched to use PLL0 and PLL1, in a separate mode switch.
And what about this 400MHz? This micro does not support more than 200MHz
//Set PLL0 to 400 MHz with 20 MHz XOSC reference. PLLDIG.PLL0DV.R = 0x50012028; //PREDIV = 2, MFD = 40, RFDPHI = 1, RFDPHI1 = 10
According to the datasheet and the AN12020 the max limit for PLL0_PHI is 400MHz.
Regards,
Cecilia
Hi,
I expect that the reason for your reset is SWT as you code is stuck on while loop.
When debugger is connected SWT is disabled by debugger.
Peter
petervlna I don't believe it is the SWT, as I disable that in the startup code. Also If I step over the SysClk_Init function call with the debugger attached I still get the reset, only if I put a break point on line 41 of the above does it pass without reset (Very Frustrating). And once it is able to pass the clk init with out resetting it seems the software will run as expected until a complete power cycle.
Also according to the datasheet and the "MPC574xR_Clock_Calculator_Rev3," 400Mhz is the max for PLL0_PHI. I am running at 400Mhz to be able to set the PER_CLK to 80MHz,
ok, in this case you should look into the RGM [DES/FES] registers for reset reason.
There is logged last reset source.
So looking at the RGM_FES I see that both F_EXR and F_ST_DONE are set. Looking at the STCU_ERR_STAT, I see that WDTO and RFSF are set. I am also seeing the external RESET pin toggle.
Is this indicating that the self test is Resting the Processor?
Hmm,
and do you run online self tests?
Because reset from offline self test is correct flag, this reset is called during reset sequence. So it has no influence on SW.
What about FES register? Is it reporting any flag?
Peter
I am not running the online self tests, The FES is reporting both F_EXR and F_ST_DONE.
-Ron
I can check your issue if you can share with me your compiled code or just binary file.
The issue is isolated to a single prototype. IE we have 3 prototypes and two of them function with the code above but one continuously resets during the clock initialization code. On that prototype we are also seeing the external reset pin toggle to low, but I do not see any other reason in the reset status registers to indicate the reason, other than external reset status is true. It does seem to run with the PLL0_PHI at 200mhz.
I am not sure if you would see the issue on a dev board, as I do not see the issue on my dev board, only on this one prototype.
Ok,
what about voltages, are they in correct range all the time?
If your reset pin is toggling then either you have periodic fault in your SW, or you have issue with power supply in some corner case. For example if CRC test is executed (high current withdraw).
Do the measurement to see if the powers are correct all the time.
If there is a significant drop, not event RGM can capture it as this module gets reset also.
Peter