SPC5746R was no longer reset

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SPC5746R was no longer reset

934 Views
chengjiangjia
Contributor II

customer found that the hardware used SPC5746RKMMT5, under the condition of repeated POWER ON and POWER OFF (5746R is supplied by 33908 POWER supply, POWER OFF means by cutting OFF 33908 POWER supply and POWER ON means 33908 POWER supply connection 12V), there was a probability that the 5746R stuck during clock  configuration (the frequency division register of DC[1] system was 2), and 5746R was no longer reset.

 At present, we have made two changes to the problem: 1. Change the cpu1 boot address 2. Use CPU0 to run the project code, and CPU1 is only used to start CPU0.No stuckoccurred after test verification. But we don't know why. Please help me to analyze it. Thank you very much!

webwxgetmsgimg.jpg

Boot address before modification:

 

    flash_rchw :     org = 0x00F9C000,        len = 0x4

    cpu0_reset_vec : org = 0x00F9C000+0x10,   len = 0x4

    cpu1_reset_vec : org = 0x00F9C000+0x14,   len = 0x4

 

Modified boot address:

 

    flash_rchw : org = 0x1000000,   len = 0x4

    cpu0_reset_vec : org = 0x1000000+0x10,   len = 0x4

    cpu1_reset_vec : org = 0x1000000+0x14,   len = 0x4

Labels (1)
0 Kudos
7 Replies

714 Views
petervlna
NXP TechSupport
NXP TechSupport

Hello,

I am not able to replicate the issue you are describing.

Core 1 is running is some dummy loop because of unversed external interrupt.

Core 0 is running into main where are some tests loops. But the SW is never stuck on clock settings.

pastedImage_1.png

As you can see I can pass it with no issues.

Do you have any more details to this issue?

regards,

Peter

0 Kudos

714 Views
petervlna
NXP TechSupport
NXP TechSupport

Hello,

But we don't know why. Please help me to analyze it. Thank you very much!

Hmm, how it behave if you put just simple example code in scenario where the device fails?

customer found that the hardware used SPC5746RKMMT5, under the condition of repeated POWER ON and POWER OFF there was a probability that the 5746R stuck during clock  configuration (the frequency division register of DC[1] system was 2), and 5746R was no longer reset.

Could you explain what happen? How cannot power on reset the device?

regards,

Peter

0 Kudos

714 Views
chengjiangjia
Contributor II

hi peter

        thank you !

        we project were created by S32_Power_v1.0 . the function named Clock_INT will be called  firstly  after the CPU1 call the  main function. After power on, sometimes the MCU will be stuck when CPU reach to MC_CGM.SC_DC[1].R = 0x80010000.In this situation, if we don't cut off the power supply connected to the 5746r, even though a hardware rest signal reach to the 5746r's rest port, the 5746r will keep stuck after reaching to MC_CGM.SC_DC[1].R = 0x80010000.

      Method one for the problem, we  change the start up address, showed as follow

    flash_rchw : org = 0x1000000,              len = 0x4

    cpu0_reset_vec : org = 0x1000000+0x10,   len = 0x4

    cpu1_reset_vec : org = 0x1000000+0x14,   len = 0x4

To our surprise, we solved the problem by changing the startup address to 0x1000000 from 0x00F9C000.

Method two for the problem, we solved the problem by using the cpu0 to run our code rather than cpu1.

#define RUN_CFG0    0

#define RUN_CFG1    1

#define RUN_CFG2    2

#define LP_CFG0     (0<<3)

#define LP_CFG1     (1<<3)

#define LP_CFG2     (2<<3)

 Clock_INT(void)

{

    PFLASH.PFCR1.R = 0xFFFF4557;    //APC=2, RWSC=5, for 200MHz, prefetch enable,

    PFLASH.PFCR2.R = 0xFFFF0057;    //Flash Port 1, prefetch enable;

    PFLASH.PFCR3.R = 0xA0000000;    //buffer partition

 

    MC_ME.ME.R = 0x000085FD;    //enable STOP/RUN0/DRUN mode

    MC_ME.IS.R = 0x000000FF;    //clear all flags;

    MC_ME.IM.R = 0x00000000;    //disable all interrupts;

    MC_ME.IMTS.R = 0x000000FF;  //clear error flags;

 

    MC_ME.DRUN_MC.R = 0x30130010;   //power level 3, PLL1/PLL0/XOSC off, sysclk is IRC 16MHz

    MC_ME.RUN_MC[0].R = 0x701300F4; //power level 7, PLL1/PLL0/XOSC on, sysclk is PLL1

    MC_ME.RUN_MC[1].R = 0x701300F4; //power level 7, PLL1/PLL0/XOSC on, sysclk is PLL1

    MC_ME.RUN_MC[2].R = 0x701300F4; //power level 7, PLL1/PLL0/XOSC on, sysclk is PLL1

    MC_ME.RUN_MC[3].R = 0x701300F4; //power level 7, PLL1/PLL0/XOSC on, sysclk is PLL1

 

    MC_ME.HALT0_MC.R = 0x20130010;  //power level 2, PLL1/PLL0/XOSC off, sysclk is PLL1

    MC_ME.STOP0_MC.R = 0x10130010;  //power level 1, PLL1/PLL0/XOSC off, sysclk is PLL1

 

    // init peripheral mode settings: all peripherals use MC_ME_RUN_PC0 and MC_ME_LP_PC0

    MC_ME.RUN_PC[0].R = 0x000000FE;

    MC_ME.RUN_PC[1].R = 0x00000000;

    MC_ME.LP_PC[0].R = 0x00000000;

    MC_ME.LP_PC[1].R = 0x00000500;  //it's for peripherals active in HALT0 and STOP0 mode

    MC_ME.LP_PC[2].R = 0x00000400;  //it's for peripherals active in STOP0 mode

    MC_ME.PCTL[9].R = RUN_CFG0 | LP_CFG0;       //LFAST

    MC_ME.PCTL[11].R = RUN_CFG0 | LP_CFG0;  //SIPI

    MC_ME.PCTL[28].R = RUN_CFG0 | LP_CFG0;  //DECIFILT_1

    MC_ME.PCTL[29].R = RUN_CFG0 | LP_CFG0;  //DECIFILT_0

    MC_ME.PCTL[30].R = RUN_CFG0 | LP_CFG1;  //PIT_RTI_0 control

    MC_ME.PCTL[31].R = RUN_CFG0 | LP_CFG0;  //PIT_RTI_1 control

    MC_ME.PCTL[36].R = RUN_CFG0 | LP_CFG0;  //DMA_CH_MUX0 - MUX2 control

    MC_ME.PCTL[38].R = RUN_CFG0 | LP_CFG0;  //CRC_0

    MC_ME.PCTL[45].R = RUN_CFG0 | LP_CFG0;  //JTAGM control

    MC_ME.PCTL[59].R = RUN_CFG0 | LP_CFG0;  //SDADC_2

    MC_ME.PCTL[60].R = RUN_CFG0 | LP_CFG0;  //SDADC_0

    MC_ME.PCTL[69].R = RUN_CFG0 | LP_CFG0;  //SARADC_2

    MC_ME.PCTL[71].R = RUN_CFG0 | LP_CFG0;  //SARADC_0

    MC_ME.PCTL[81].R = RUN_CFG0 | LP_CFG0;  //FlexCAN_2

        //here the MPC5746R.h is updated to make PCTL81 available

    MC_ME.PCTL[83].R = RUN_CFG0 | LP_CFG0;  //FlexCAN_0

    MC_ME.PCTL[85].R = RUN_CFG0 | LP_CFG0;  //LINFLEX_M0

 

    MC_ME.PCTL[90].R = RUN_CFG0 | LP_CFG0; //LINFLEX_3

 

    MC_ME.PCTL[91].R = RUN_CFG0 | LP_CFG0;  //LINFLEX_2

    MC_ME.PCTL[92].R = RUN_CFG0 | LP_CFG0;  //LINFLEX_0

    MC_ME.PCTL[96].R = RUN_CFG0 | LP_CFG0;  //DSPI_M0

    MC_ME.PCTL[97].R = RUN_CFG0 | LP_CFG0;  //DSPI_4

    MC_ME.PCTL[98].R = RUN_CFG0 | LP_CFG0;  //DSPI_2

    MC_ME.PCTL[99].R = RUN_CFG0 | LP_CFG0;  //DSPI_0

    MC_ME.PCTL[102].R = RUN_CFG0 | LP_CFG0; //EMIOS 0?1?

    MC_ME.PCTL[104].R = RUN_CFG0 | LP_CFG0; //SENT_0

    MC_ME.PCTL[143].R = RUN_CFG0 | LP_CFG0; //DMA_MUX3

    MC_ME.PCTL[166].R = RUN_CFG0 | LP_CFG0; //CRC_1

    MC_ME.PCTL[188].R = RUN_CFG0 | LP_CFG0; //SDADC_1

    MC_ME.PCTL[196].R = RUN_CFG0 | LP_CFG0; //SARADC_3

    MC_ME.PCTL[197].R = RUN_CFG0 | LP_CFG0; //IGF

 

 

 

    // Init PLL0: 16MHz / 1 * 50 = 800MHz VCO, 800MHz/8RFD = 100MHz PLL0PHI output, 800MHz/12RFD PLL0PHI1 output to PLL1

    //PLLDIG.PLL0CR.R = 0;

    PLLDIG.PLL0DV.B.PREDIV = 1;     //pre-divider is 1

    PLLDIG.PLL0DV.B.MFD = 50;       //multiplier is 50

    PLLDIG.PLL0DV.B.RFDPHI = 8;     //post divider is 8, so PLL0PHI = 16*50/8 = 100MHz

    PLLDIG.PLL0DV.B.RFDPHI1 = 12;   //post divider is 12, so PLL0PHI1 = 800/12 MHz;

                                    //

    // Init PLL1: 66.7MHz input from PLL0_PHI1, 66.7MHz * 12 = 800MHz, 800MHz/(2x2) = 200MHz;

    PLLDIG.PLL1DV.B.MFD = 12;       //multiplier is 12

    PLLDIG.PLL1FD.R = 0;            //fractional divider is disabled

    PLLDIG.PLL1DV.B.RFDPHI = 2;     //post divider is 2

 

 

    MC_CGM.SC_DC[0].R = 0x80000000; //clock divider 0 (200MHz) for Core SysClk, FXBAR   (max 200MHz)

 

    MC_CGM.SC_DC[1].R = 0x80010000; //clock divider 1 (100MHz) for SXBAR            (max 100Mhz)     Sometimes the MCU will stuck here

0 Kudos

714 Views
petervlna
NXP TechSupport
NXP TechSupport

Hi,

Are you using NXP eval board or custom build one?

Could you share with me code (or output file) where is the failure so I can test it here?

regards,

Peter

0 Kudos

714 Views
chengjiangjia
Contributor II

hi peter

   

     The file [LQ_FCT_TEST_Z4_2.ZIP] are the elf and s19 file for cpu1 and the file[LQ_FCT_TEST_Z4_1] is the elf for cpu0. In the main function, we use SIUL2.GPDO[125], SIUL2.GPDO[126].R, SIUL2.GPDO[127].R control 3 led in our hardware to turn on or turn off. A part of code are as follows

 

     for( ; ; )

    {

        if(counter<100000)

        {

            SIUL2.GPDO[125].R = 1;

            SIUL2.GPDO[126].R = 1;

            SIUL2.GPDO[127].R = 0;

        }

        else if(counter<200000)

        {

            SIUL2.GPDO[125].R = 1;

            SIUL2.GPDO[126].R = 0;

            SIUL2.GPDO[127].R = 1;

        }

        else

        {

            counter=0;

        }

       counter++;

   }

 

   If the MCU is stuck when reach to MC_CGM.SC_DC[1].R = 0x80010000, then we will not see the led flashing. Because our project has to many C files, we share you the output file firstly . if necessary, we will share you a sample project which has the same problem later.

   So far, we seems to have further discovery on the problem. If we download cpu0 and cpu1 code to 5746r together, the problem seems to be solve. And if we only download the cpu1 code to 5746r, the problem happen frequently.

        thank you very much !

0 Kudos

714 Views
petervlna
NXP TechSupport
NXP TechSupport

Hi,

I have loeaded your elf files to micro.

But the LQ_FCT_TEST_Z4_2.elf shows no code. Looks like there is some issue with this elf. Could you regenerate it?

LQ_FCT_TEST_Z4_1.elf is working correctly.

pastedImage_14.png

regards,

Peter

0 Kudos

714 Views
chengjiangjia
Contributor II

thank you peter !

share a sample project which has the same problem.

0 Kudos