MPC5777C: Reconfiguration of the system clock fails

[BG]

Hello,

we want to reconfigure the system clock from 300 MHz to 200 MHz to execute the BIST of the MPC5777C.

For this we use the clock configuration code as given by "MPC5777C-Online-MBIST+LBIST-v1_2-GHS614.zip" from https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/MPC5777C-Online-BISTs/ta-p/1124355. The only change to this is the switch from the peripheral clock to the FM clock domain instead of the PLL0 (SIU.SYSDIV.B.PERCLKSEL = 0;).

However, sometimes the reconfiguration of the clock fails in one of two ways:

1. In some cases the PLL0 does not lock. Looking at the PLLDIG.PLL0CR register shows that the CLKCFG entry remains set to 0 even though it was set to 0x3 before waiting for the PLL0 lock (PLLDIG.PLL0CR.B.CLKCFG = 3; //turn on PLL0).
2. In other cases the program execution seems to be incorrect. A data storage exception is raised, with the SRR0 address pointing to an address that lies inside of a valid assembler instruction:
   SRR0 contains the value 0x84160A which points to an address within the 32-bit e_ori instruction at address 0x841608.
   Note: The screenshot shows the register context within the exception handling routine and thus does not show R0 to R31 as they were when the problem occurred.

Curiously the issue seems to happen far less often if I add waiting loops before and after changing the system clock to the IRC.

Are there instructions or an example to properly reconfigure the clock to avoid these Problems?

Regards,
Bernd

[petervlna]

Hello,

In some cases the PLL0 does not lock. Looking at the PLLDIG.PLL0CR register shows that the CLKCFG entry remains set to 0 even though it was set to 0x3 before waiting for the PLL0 lock (PLLDIG.PLL0CR.B.CLKCFG = 3; //turn on PLL0).

It can be that you were running peripherals from PLL and they are still using that clock in time you are requesting change.

Therefore some delay loop will resolve the issue.

In other cases the program execution seems to be incorrect. A data storage exception is raised, with the SRR0 address pointing to an address that lies inside of a valid assembler instruction:

In my opinion it depends on if the accessed location is still validly clocked. In debug mode you wont spot it as there is a lot of delay added by debugging.

Are there instructions or an example to properly reconfigure the clock to avoid these Problems?

Unfortunately I have created only the PPL0 clocking example.

When you switching the source clocks, it is recommended to ensure that peripherals using the actual clock are not executing/requiring that clock in time you perform change. Otherwise the change will be refused.

Best regards,

Peter