Strange problem while setting PCTL on MPC5748G

[alexvinchev]

Hi,

I'm using more extensively MPC5748G and noticed strange problem with my code.

In the attached test project (working in the same way on CUT1 & CUT2 MCUs) I'm unable to stop CAN clocks which are already started.

Am I doing something wrong, or ...? Could someone give me advice what to check or what I'm doing wrong?

Source code is based on "AN4830 Qorivva Recipes for MPC574xG".

Compiler: GHS MULTI 6.1.6

Debugger: Lauterbach

Best regards,

Aleksandar

AN4830 ,Qorivva Recipes for MPC574xG

Original Attachment has been moved to: MPC5748G.7z.zip

[alexvinchev]

Problem was solved petervlna​

By number of reasons CAN4 cell was not stopping correctly, which forced (I guess) chip to not switch off the clock, supplied to the module.

Best regards,

Aleksandar

[petervlna]

Hi,

I am using cut 2.0 and there is no issue with PCTLx for clock disabling.

Example:

I am using PC0 as a default power mode for peripherals. Where all my CANs are active.

Now I will dissable clock to CAN0.

For example set PCTL70 (CAN0) to ME_RUN_PC1.

Now perform mode transition to activate the new power profile RUN_PC0 where the CAN0 is excluded:

And the result is:

And really the CAN0 module clock is not present

Peter

[alexvinchev]

Hi Peter,

thank you for your answer.

Did you had chance to look at my code?

When I run it, I'm staying in the loop:

while(MC_ME.GS.B.S_MTRANS == 1);

I've checked peripheral registers and S_MTRANS is really 1.

What could cause such effect?

My code was compiled with GHS compiler 2014.1.6, I'll be tomorrow at the office and will try 2015.1.6.

Best regards,

Aleksandar

[petervlna · Accepted solution]

Hi,

I did not checked your code.

I created for you simple example code for demonstration.

Peter

[alexvinchev]

OK petervlna​

I confirm, everything works with simple example... BUT...

Let me share my findings...

1. I've noticed that (according to your Lauterbach scripts) you are using CUT1 device. Your supplied scripts are not working on CUT2 devices because of changes in watchdog... This really doesn't matter for this subject...

2. Even if simple examples work, more complex code doesn't. In my case I'm really facing very strange behavior from both CU1 & CUT2 devices (checked also on the evaluation board and with the newest available GHS compiler as I wrote above).

Because it was hard to explain and you most probably will not have time to look code in details I've made few screenshots and mode changes trace to illustrate the problem...

Finally, mode change tracelog looks like this:

where:

     - actual is current MCU run mode;

     - new is the mode to which we should switch;

     - pctl is PCTL register number if its value was changed before mode requesting mode switch;

     - pctl_val is the new value of PCTL above;

There is special case, where PCTL is not changed. This is shown by pctl = 0xFF, pctl_val = 0xFF

So, after 18 mode switches, on 19 my system refuses to switch its mode.

All images that follow are big enough to see the details...

This is system state before start (only run to main, which includes some system initialization calls):

This is system state after CAN initialization (normal system run):

Then, I'm stopping the system and CAN0-3 are already stopped here:

And this is system state one step before death (endless loop):

Mode switch is implemented as follows:

I hope now its more clear... You can see that I'm using three RUN_PC modes:

#define MPC57XX_DEFAULT_CLOCK_STOP	0
#define MPC57XX_DEFAULT_RUN_MODE	1
#define MPC57XX_DEFAULT_LP_MODE	7

When I execute described sequence on my system after setting of PCTL 74 I'm staying in the endless loop, checking S_MTRANS, which always stays 1, which is also seen in the last of big pictures above. System reports through CDP_PRPH_64_95 that "Clock disabling is pending for at least one peripheral" in this group (74). And this stays forever, because my watchdog is OFF for now, but watchdog reset is not real solution for me. If I remove call to clock stop of CAN4, rest of the CAN clocks are stopped fine. Problem is only with CAN4...

Sorry for the long post, but I didn't really figure out how to make it shorter...

[alexvinchev]

Peter, please don't get me wrong... I'm not asking you to debug my system...

I've already verified, that If I replay same steps with just starting/stopping clocks everything also works, but somewhere there is something in my system which causes strange behavior, described above...

I'm asking for your advice - where to look, what to look, what to check, what could be the possible reason for such behavior in order to chase it and solve it...

[alexvinchev]

Hi Peter,

Thank you for your example. I will try tomorrow, but I'm hardly suspecting that problem is when clock start/stop is called in sequence, like in my code. I'm initializing at once (but sequentially) CAN channels 0-5 and then I'm trying to disable them. This is happening, because I have CAN driver in my OS and each CAN initialization starts CAN clock, then each CAN de-initialization stops the clock. In my original code when I start CAN0-5 it hangs when I try to stop clock of CAN4 (CAN0-3 are stopped successfully), in the code example, attached to this thread (far, far simpler than original code) problem happens even earlier, when I try to stop clock of CAN0. This is what I don't understand... really... This is also the reason to wonder what could cause this problem. Obviously, you didn't face it before, otherwise it will be known and easy to answer...

One thing that I didn't tried is to start my example code from above on the evaluation board for MPC5748G. I'll try this one tomorrow as well...

Aleksandar