5744P crashing from call to SDK ClockMan

[QES]

Hello,

Devkit SPC5744p Rev E board.

S32DS with 3.0.3 SDK

If I use the generated code from example projects, or if I create my own S32 application using the SDK, then the processor crashes as soon as call to MC_ME_ChangeMode to change to PLL from int osc..

If I hit breakpoint just after this, and continue program then code will not crash.

If I use example, or start new project, then I must change PBRIDGEx_CLK to divide by 4, as all examples and processor expert from new project have this value wrong.

Am I missing something else that is also wrong?

Are other people able to run SDK code on the Rev E dev kit?

It makes no difference if compile with or without Optimisation, or if i debug from Flash or RAM.

Please see attached project, does this run for anybody else?

It is just an empty project, but the code will crash inside CLOCK_SYS_UpdateConfiguration.

If I hit breakpoint here, and continue, then program is fine.

[QES]

OK, I have managed to make some progress.

The default processor expert config, does not work on my SPC5744P. The issue seems to be that the SYS_CLK can not be 200MHz.

By default the configuration is set to use PLL0_PHIO as the SYS_CLK. I need to drop the PLL0_PHIO frequency below 200MHz and the code will run successfully. However, from my reading, and the Spreadsheet provided in the download area for DEVKIT-MPC5744P it sounds like it is preferable to use PLL1_PHIO for the SYS_CLK (cascaded from PLL0). Again this works, as long as the frequency is below 200MHz. The reference manual also states that the core is clocked from PLL1, so it is hard to understand the logic of processor expert who sets PLL0 to 200Mhz and PLL1 to 100MHz.

I can get the code to run if PLL1_PHIO is 180MHz, but if I go to 190MHz or above, I see the crash. I have experimented with various settings, trying to disable as much else as possible but I can not get the device to clock at 200MHz.

I am also confused how it is possible to achieve exactly 200Mhz, since PLL1 adds on a small fractional part, which takes the frequency slightly over 200Mhz, then generates a warning. (regardless of whether I use the fractional divider part or not).

I had assumed that the default settings provided would have at least worked, but this is giving me a lot of problems. I have only investigated the clock and PLL settings so far, but I will keep in mind that the processor expert can not be trusted when generating any configuration. I was already suspicious of the configuration because I had already encountered this mistake  that the peripheral clock by default is too fast.

Thanks for testing the code so far @petervlna, but your test leaves more questions than answers for me.

Are you able to test this on the SPC5744PFMLQ9, better still on the Devkit? and using the PE debugger?

I am wondering if there could be an issue with the debugger? As originally stated, if I hit a breakpoint when the PLL is configured, then step over, then resume I do not see the problem. MC_ME_ChangeMode(MC_ME); -> step -> then run

I have tried adding similar delay for-loops before the PLL is set up, and the debugger gives the same error, believing the program has locked up?

I seem to be having the issue at a similar delay for loop while we wait for mode change to take place.

for (i= 0U; i < MC_ME_COMPLETE_TRANSITION_TIMEOUT; i++)
{
/* Check whether transition completed */
if (MC_ME_GetTransitionStatus(MC_ME))
{
retValue = STATUS_SUCCESS;
break;
}
}

[QES]

So the error message is referring to a repository. I only installed S32 PA a few weeks back, I don't recall selecting any repositories.

I also noticed that when I do create a project, the device is set to MPC5744P_257, which is for a BGA device. I am unable to change this, but my device on the dev board is a 144 LQFP.

Does this provide any additional info for you?

[petervlna]

Hello,

When I tried to compile your project following error occurred:

Are you sure you have created project for MPC5744P?

But I have tested your code at my EVB (MPC57xx+MPC5744P minimodule). the clock setting was sucessfull and I can run the code to the point

without any issues in debug/standalone mode. I do not see any clock issues here.

Best regards,

Peter

[QES]

Hi Peter,

Can you think of any way to move this problem forward?

I hope the first screen shot shows that I selected 5744p as the device. (Note mine is a SPC automotive).

Could this be part of the problem, your IDE has converted the processor expert code, so now it works? 

Can you send me back the converted project, and I will look to see if anything is different?

Do you think the board I have is faulty?

Is there anything I can check to help find the problem?

I am unable to move forward with the project we selected the device for...

[petervlna]

Hello,

Could this be part of the problem, your IDE has converted the processor expert code, so now it works?

Hmm, I simply compiled it to be able run it in my EVB. I did no changes.

Can you send me back the converted project, and I will look to see if anything is different?

It is attached.

Do you think the board I have is faulty?

Hmm, I dont think so. I would check the XOSC and I would also try to generate the PLL from the IRC.(this will exclude any issues with HW)

Is there anything I can check to help find the problem?

I never used the processor expert as I like to have code my under control. So maybe you can try some of our example codes based on bare die code.

In case of any further questions/issues do not hesitate to ask me.

best regards,

Peter

[QES]

Hi @petervlna 

Thanks for getting back to me. Your answer has moved things forward. 

Before I explain about that, I will say I have spent over 100 hours investigating this.

I had determined that this was not a software problem. Partly from your tests, however your 5744P is a different variety to mine, as I have the SPC5744P FMQL9 (Mask 1N15P). Anyway I got to the point where I understood each clock setting in the processor expert, and from trial and error was able to determine that the issue was due to the SYS_CLK being set above 180 MHz. I tried running it from both PLL's and went through the processor expert and made sure all peripherals were being clocked in frequency spec (then turned them off). (By default some of these can be wrong).

I also felt it was hardware, as the tell tale was that stopping the debugger when MC_ME enables the PLL, restarting debugger then allowed the code to run at 200 MHz. Looking in to the driver, I found a few more minor issues, the driver sets both PLLs up then makes one call to MC_ME to enable them both. The reference manual reads that when PLL1 is driven from PLL0, PLL0 should be running first before enabling PLL1. This didn't help, but it was worth a try. My overall clock scheme currently is PLL1 at 180MHz, driving SYS_CLK (everything the other side of PCFS). PLL0 driving the peripherals that need a different clock source, as much as possible switched off. My device does not have Ethernet e.g. so switched off.

The actual crash seemed to be happening just after the mode change, when the driver polled for the MC_ME status to report the mode change. This is inside a for loop waiting for the bit to change. I tried adding more delay code, making the program counter jump around a bit, and sometimes could get up to 190MHz SYS_CLK. I am still not sure if it is something to do with the PE debugger, though last time I flashed a project I recall it didnt run, but my knowledge has moved on a lot since then. I may try this again (EXT_OSC @ 200MHz).

I was at the point where I really couldn't put any more time in to it, due to the requirements of the project using the 5744. (Lucky I had the festive week as an extra week).

Anyway, your suggestion has helped - I had not thought of trying the IROSC as the clock source, and this confirms that the processor can run at 200Mhz from that source. Therefore reinforcing all the evidence that there is a hardware issue with the PCB. Not sure whether it is the batch, or I was just unlucky. It would seem that the PLL is taking too long to settle, or becoming unstable while it settles, enough to replicate a crash back in S32.

I will take the issue up with my supplier, I shall order a new board first to see if the problems persist. To be clear for anyone following this, This is the DEVKIT 'REV E' board bought in the UK from UK supplier.

I did try the stabilise counter on PLL0, but this does not help.

I feel a lot happier knowing the settings are right and so is my understanding. 

Please let me know if you have any more comment, or anything to try related to the EXT_OSC. 

I expect I will have more questions in the future. Cheers QES.

[petervlna]

Hello,

Well I do not have rev E board here, I am doing all test on MPC57xx motherboard + MPC5744P minimodule.

Looks like I will order rev E for tests, to see if there are any issues with the HW.

Try this example on your revE, where I have set all clocks to max frequency. No tool is used to generate code. It is precompiled, but if you wish to compile it use GHS compiler 6.14 or higher.

best regards,

Peter

[eusebiu_bivol]

Hi @petervlna,

I am facing the same issue as @QES.

I have two MPC5744P evaluation boards, rev. E. I have build a project using Processor Expert and exact same code is running with one board, but with the other one it crashes during clocks initialization.

I have tried what @QES found out during his investigation, to use the IROSC instead of XOSC, but even like this, if I do not pause the execution before mode change, it crashes.

The difference between the two board is the MCU type. The one which works is equipped with SPC5744PFMLQ9 1N15P QMZFT1928J and the other one with SPC5744PFMLQ9 1N15P QMZDR1915R.

Do you have news regarding this problem, some workarounds or fixes?
Thank you!

[QES]

Hi, I have not managed to solve this issue. I believe the PLL becomes unstable. I still have the board, but also saw it on a customer board too. MY IC part number is:

SPC5744PFMLQ9 1N15P QMZDR1922L

I made sure that the software I produced only used 180Mhz clock rate, to be sure it would work on any device it was deployed on to.

[eusebiu_bivol]

Hi @QES, thanks for reply.

Please have a look into AN12017 SW.

Here the system clock is set to 200MHz via XOSC. I just copy pasted the clock configuration part into my project and it seems to work on my board. The configuration is not done via Processor Expert.

I do not completely understand yet what is happening there, but considering your experience you might understand and identify the root cause of our problem.

I will continue my tests and please let me know if this information was useful to you.

[QES]

Hi Peter,

Yes I think you should get a RevE board.

Thanks for your continued help, and sending the source code. The code crashes before returning from Sys_Init(). If I single step through then the code will complete this function.

I tried to put break point to see where code fails, and it seems to be in the final 3 lines - the 3 while loops. The next line after this is unreachable:

while(MC_ME.GS.B.S_MTRANS); //Waiting for end of transaction

But here I noticed that you are still dealing with PLL0. I wonder if here you meant PLL1? Can you check the last few lines, and make sure you are happy with them please?.

I did swap the first while loop to wait for PLL1 to stabilise, but it still crashes in the same place. 

PS, also now running on external power supply, rather than USB, but makes no difference.

PLLDIG.PLL1DV.R = 0x00020014; // MFD = 20, RFDPHI = 2

//Mode transition to apply the PLL0 setup and set Normal mode with PLL running
MC_ME.MCTL.R = 0x30005AF0; //DRUN Mode & Key
MC_ME.MCTL.R = 0x3000A50F; //DRUN Mode & Key

while(!MC_ME.GS.B.S_PLL0); //ME_GS Wait for PLL stabilization.
while(MC_ME.GS.B.S_MTRANS); //Waiting for end of transaction

<Cant get here>

while(MC_ME.GS.B.S_CURRENT_MODE != DRUN_MODE); // ME_GS Check DRUN mode has successfully been entered

}//Sys_Init