Obtaining shortest FMPLL timing possible, with MPC5634M

[andydcoles]

Have a fairly small Development Application (<3kB), Safety Critical.  Currently running on a TRK-MPC5634M Demo Board.

Requirement is for the Function start to execute, as close to MCU Power-up, as is possible.  Wanting to shorten the time FMPLL takes to complete, to an absolute minimum.

The FMPLL Coding, is based upon the helpful "AN11960.pdf" Document.

A stepped approach was employed, safely affording some overshoot of the initial 64MHz Clock, before stepping to the maximum 80MHz Frequency for the MPC5634M Device.

This final Frequency could likely be lowered (say to 64MHz), if the FMPLL could be accelerated.  With a lower initial Clock (say 40MHz, or even 32MHz).

It would appear that the "FMPLL.ESYNCR1.B.EMFD" setting might affect how aggressively the FMPLL is able to lock, in terms of time taken.

Here's the complete FMPLL Implementation:

// Disable clock monitoring flags (loss of Lock, Clock Reset & lock IRQ)
FMPLL.ESYNCR2.R = 0x00000000;

// Disable PLL. Clock Mode bypass of 8MHz Crystal Reference.
FMPLL.ESYNCR1.B.CLKCFG = 0x01;

// Configuration set to Enhanced Mode.
FMPLL.ESYNCR1.B.EMODE = 0x1;

// Setup ERFD PLL Ramping Step to minimum value of zero (divide by 2)
FMPLL.ESYNCR2.B.ERFD = 0x0;

// Setup EPREDIV Enhanced Divider to 4 (divides 320MHz VCO by 5) to
// target initial 64MHz Clock.  FMPLL could safely overshoot this (some).
FMPLL.ESYNCR1.B.EPREDIV = 0x04;

// Enhanced multiplication factor-divider. Divides by 40, here.
// Not sufficiently explained how this works....
FMPLL.ESYNCR1.B.EMFD = 0x28;

// Set Clock Mode to Bypass, Crystal Ref. and PLL on.
FMPLL.ESYNCR1.B.CLKCFG = 0x03;

// Wait for intermediate 64MHz Frequency to lock. N.B. The LOCK bit is b28.
while (FMPLL.SYNSR.B.LOCK == 0) {}

// Update EPREDIV Enhanced PRE-DIVider to 3 (divide 320 MHz VCO by 4).
//
// Selects the final target Frequency at nominal MPC5634M 80Mhz maximum.
FMPLL.ESYNCR1.B.EPREDIV = 0x03;

// Configure Clock as normal with Crystal Reference FMPLL on, to complete.
FMPLL.ESYNCR1.B.CLKCFG = 0x07;

[andydcoles]

Hi SebastianG

PLL doesn't appear to be that slow, compared to typical MCU PoR.

The reason I ask, is for a Control Application that needs to start, ASAP.

We'd likely get more mileage out of shortening PoR duration, to the lowest recommended value.

Best Regards

Andrew

[SebastianG]

Hi @andydcoles,

Unfortunately that is not possible, you cannot modify the POR timing it is required to follow the default POR sequence in order to have a successful boot.

Regards

[andydcoles · Accepted solution]

Thanks for that Information.

I had hoped that the POR period might have been extended on the TRK-MPC5634M Board. 

Was using one to measure Timings on a 'Scope shortly after entry into main() (immediately after initializing GPIO Ports and asserting outputs captured via P5 eMIOS Pins), and again after a two Stage PLL to 80MHz, completed.

It is for a Control Application, driving and monitoring custom Electronics.

Not likely to be a problem, for Automotive use!

[SebastianG]

Hi @andydcoles,

Could you please share with me a log with the results of your implementation?

Regards

[SebastianG]

Hello @andydcoles,

I'm working on your question, When I have any update I will let you know

Regards