PLL in M52235

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

PLL in M52235

5,047 Views
mjbcswitzerland
Specialist V
Hi
I am rather confused about the PLL in the M52235.
Accoring to the documentation, the 25MHz cyrystal frequency should first be divided to within the range 1..10 MHz. This is done by programming MCF_CLOCK_CCHR. Then the frequency is multiplied by 12 to get the maximum frequency of 60MHz.
 
My findings have been that it doesn't react to CCHR settings. It seems as though there is a fixed divide by 5 in the input because the *12 really does give 60MHz.
 
Looking at example code in the CodeWarrior project delivered with the EVB I see that the CCHR setting is commented out - also according to the documentation a value of 4 and not 5 in the register would give the /5 (?). Here is the code from CodeWarrior files:
 
void
mcf52235_pll_init(void)
{
//MCF_CLOCK_CCHR =0x05; // The PLL pre divider - 25MHz / 5 = 5MHz
 /* The PLL pre-divider affects this!!!
 * Multiply 25Mhz reference crystal /CCHR by 12 to acheive system clock of 60Mhz
 */
 MCF_CLOCK_SYNCR = MCF_CLOCK_SYNCR_MFD(4) | MCF_CLOCK_SYNCR_CLKSRC| MCF_CLOCK_SYNCR_PLLMODE | MCF_CLOCK_SYNCR_PLLEN ;
 while (!(MCF_CLOCK_SYNSR & MCF_CLOCK_SYNSR_LOCK))
 {
 }
}
 
Then the last thing that I see is that the PLL locks but the value in SYNSR is 0x38. The SR in the documentation has bit b00100000 always as zero so this should not be able to happen.
 
Is the design of the PLL really different in the M52235? Has the (preliminary) documentation not yet been adapted?
 
Any ideas?
 
Regards
 
Mark Butcher
www.mjbc.ch
 
Labels (1)
0 Kudos
5 Replies

657 Views
jwbodnar
Contributor I
Mark,

The PLL on the MCF5223x is the same as on the MCF5213.

What has changed is that we added a programmable divider in front of the PLL reference input.

So, the 25 MHz reference clock (either from the output of the crystal oscillator or input rail-to-rail directly on EXTAL) is sent straight to the Ethernet PHY.

It also goes to the reference pre-divider so that you can divide it down into the PLL's 2 to 10 MHz input range.

We default this prescaler to divide-by-5 so that you can simply multiply it by 12 to get the 60 MHz maximum frequency.

Most folks probably won't change the pre-divider, but you can do so if you need to run at some frequency that isn't a multiple of 5 MHz. Just make sure the PLL is disabled when you do so. Although the pre-divider is outside of the PLL loop, it does change the reference frequency and will force the PLL to re-lock.
0 Kudos

657 Views
DrSeuss
Contributor I
Mark,
I do not completely understand what you are trying to do. Perhaps one thing is misunderstood.
The Ethernet PHY requires a 25MHz input (crystal) in order to function, this is not optional.
 
While I think I have tested this register to be writable, I see no reason to do so.
0 Kudos

657 Views
mjbcswitzerland
Specialist V
Hi

Let me explain why this is important.

The project requires Ethernet and so a 25MHz crystal is required.
The project also requires two serial interfaces operating at 250kBd (this can not be changed since it is defined by the other side).
This means that we need to program the serial baud rates to as close to 250'000 Bd as possible to enable it to work.

The PLL value is given by 25MHz (can not be changed due to Ethernet) divided by CCHR (default /5) = 5MHz * PLL_MUL / PLL_DIV.

In order to generate 250'000 Bd from the UARTS a bus speed of a multiple of 8MHz is required so that it can be divided down to give the exact frequency. 56MHz would be suitable.

60MHz PLL operation allows either 234,375 Bd or 267,857 Bd which is obviously unacceptable.

If the PLL is set to *8 = 40MHz it is possible to generate 250'000 Bd exactly but at the expense of reduced processing speed.

If however the CCHR value is set to /4 it gives a PLL input frequency of 6,25MHz (withingthe range 1..10MHz). This can them be multiples by 9 in the PLL (*18 / 2) to give a bus speed of 56.25MHz.
This then allows the UART to achieve 251'116.1 Bd (+0.4%) and so adequately accurate for ASYNC operation with minimum bus speed reduction.

The reason for wanting to do this is therefore easy to justify since it saves wasting processor speed due to the UART requirement. Alternatively it saves having to add an external 4MHz clock to the UART clock input to achive the UART accuracy while staying at highest bus speed.

My attempts to achieve the required division at the input to the PLL (from default /5 to the optimum /4) have not been successful. Although the register is readable and writable (the lowest 3 bits are writable, the higher 5 are always read as '0') it has not been possible to influence the PLL output (as if the /5 at the input is fixed) and so we still have difficulties confirming a customer that his design will be possible. The project should start mid-September but this is a blocking issue since he is neither happy with an additional crystal nor with the slower processor speed.

Can you confirm that the CCHR register is operating correctly (it seems to be new in the M5223X) or explain how it is to be used to take effect? Note: Its value is being set before enabling the PLL.

Regards

Mark
0 Kudos

657 Views
mjbcswitzerland
Specialist V

Hi

I have returned to the subject because of the need to set a different divide value before the PLL input.

Unfortunately I still have the problem that the device is not responding to changes of the prescaler (MCF_CLOCK_CCHR).

To be sure that I am not changing the registers incorrectly I have added a memory dump of the first 16 bytes in the clock module peripheral space. This has confirmed that the MCF_CLOCK_CCHR value is defaulting to 4 (divide by 5) and then my code is setting it to 3 (divide by 4). This is performed with disabled PLL and the SYNCR register is each time afterwards written with a multiplication factor of x9 (div. 2 *18).

The PLL output is constantly 45MHz, irrespective of whether CCGR is set to 2, 3, 4 or 5.

This gives the impressions that the register can be written and read but the divide is fixed to 5.

Here are register details after booting and not attempting to set CCGR (all addresses are (byte) dumped incl. non-used, starting at IPSBAR + 0x12000).
0x71 0x07 0x38 0x00 0x01 0x94 0x00 0x00 0x04 0x00 0x00 0xf0 0x01 0x7d 0x78 0x40
The value 0x04 is seen at (IPSBAR + 0x120008) and the PLL output frequency is 45.0MHz. The status register shows that the PLL is locked, etc.

Here is the dump when CCGR is set to 0x03
0x71 0x07 0x38 0x00 0x01 0x94 0x00 0x00 0x03 0x00 0x00 0xf0 0x01 0x7d 0x78 0x40
It shows that the correct location has been modified and the PLL is locked. Still the PLL output frequency remains at 45.0MHz
If I set 0x08 to CCGR it reads back 0x00 (since only the lowest 3 bits can be written to), confirming again that the register is really being set correctly.

Please could you inform me whether this is a problem with the device or whether there is some special handling required to get the register value to be accepted for the prescaling?

Many thanks in advance.

Regards

Mark Butcher
www.mjbc.ch

0 Kudos

657 Views
mjbcswitzerland
Specialist V
Great, that seems to explain it all.
 
I was confused due to three points:
1. In the data sheet it shows the reset value of the new register to be 0, which is probably not correct. (0 means divide by 1)
2. In the example code there was a line programming with 5, which was commented out. I think that 5 would actually divide by 6 so this is probably not correct if comment in.
3. I played around with the multiplication factor and got expected reactions but I got no reaction when playing around with the CCHR value - I assume this is because I didn't disable the PLL between changes.
 
Therefore I am happy with the code - I have left the CCHR at the default setting and get 60MHz by programming x12 so no need to change this normally.
 
Regards
 
Mark Butcher
 
0 Kudos