M52235 PLL

[mjbcswitzerland]

Hi

[This is an udpate of the post http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=236&query.id=985#M236]

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

[DrSeuss]

The PLL must be disabled MCF_CLOCK_SYNCR = 0x0000; the PFD modiifed and then re-enable the PLL
At least this worked for me. Also, the PLL comes up from reset enabled so you must do the disable step.

On other ColdFire devices it is possable to boot with the PLL disabled. This is why the sister chip did not have this issue.

[mjbcswitzerland]

Hi

Sorry to go on but I'm still not convinced. I sat down and very carefully checked out several things using a very simple test with the BDM.

1. Reset the M52235 and don't execute any instructions - all registers are in their default states. SYNCR is 0x1002 as in the data sheet - this indicates that the PLL is OFF by default and not on.

2. I manually configure TOUT0 to generate a frequency derived from the bus frequency (measured with an oscilloscope). This is the sequence: DTRR0 = 0x000000ff -> DTMR0 = 0x002D -> PTCPAR = 0x02 [last connects the Timer output to the port pin]
Now there is a square wave on the output pin of 3,05kHz.
Its frequence is derived from Bus clock / 16 / 256 / 2 = (Crystal is 25000000 / 16 is due to the DTMR0 configuration to divide its input by 16 / 256 is the reference in DTRR0 and /2 is the fact that it requires 2 periods to generate one cyce of a square wave.
25000000/16/256/2 = 3'051.76kHz. This corresponds with the measured frequency and reinforces the fact that the PLL is not enabled since the bus frequency is equal to the crystal frequency.
In addition SYNSR is showing 0x20 (PLL not locked)

3. Now I modify the SYNCR register to see what happens.
SYNCR = 0 (to ensure PLL not enabled) - no change at timer output - still 3.05kHz
SYNCR = 0x1003 Status indicates that the PLL is locked but frequency remains the same (since bus is still coming from crystal input)
SYNCR = 0x1007 now PLL is connected to bus and the frequncy changes to 3.66kHz.
This is because the PLL is generating (25000000/5(CCHR))*6 = 30MHz, which then gives this timer output.
SYNCR = 0 stop again - frequency returns to 3.05kHz. Status shows PLL not locked
SYNCR = 0x4007 - frequency becomes 7.31kHz - status shows PLL locked. Again this is correct since the PLL is now (25000000/5)*12 = 60MHz - the timer output is as expected.
SYNCR = 0 - stopped again and timer output 3.05kHz
CCHR = 3 - this should change the input divide (the register reads 3 back)
SYNCR = 0x4007 - Timer output is again 7.31kHz

This shows that the value in CCHR is still not causing any changes.


This means that I am definitely disabling the PLL when making changes. I don't find that the PLL is enabled out of reset. I also do not find the CCHR register with a search in the MCF52223 documentation.


If you managed to get a reaction please explain with which method you tested. Do you have the same chip on your EVB (I have the PCF part)?


This leads me then back to the original problem. How to generate a clock for the 250kHz UART. Here there seems also to be a complication. It I connect the DMA Timer output to the UART clock input it needs to be 16x the Baud rate. This means it needs to be 4MHz and not 250kHz. If I try to set up the DMA timer to generate this it is found that it must toggle at twice this rate to generate a 4MHz clock signal.
The value needed is therefore 7.5 (with the divide by 16 disabled)!! This puts me back to square one again since the accuracy is the same as using an internal clock. Also here the optimum solution is to set the PLL to 56.25MHz so that a divide by 7 is accurate enough.

So where am I going wrong and why does it work for you?

Thanks in advance.

Regards

Mark

[flashtoo]

Has anyone been able to resolve this issue? I too have not been able to get the CCHR to have any affect. I even tire the code from the cInit tool with no luck.

FlashToo

[mjbcswitzerland]

Hi

I have finished the above mentioned project using 40MHz clock - with DMA on RX and TX UARTs the speed was adequate.

After various attempts I never did get the PLL to the settings that I wanted and so am still of the opinion that there is a problem there somewhere.

Regards

Mark

www.uTasker.com

[flashtoo]

FYI, This is what I got from Freescale Support about the CCHR registister..

"Unfortunately, this function does not work in MCF5223x. I found It is being fix for the next Silicon. Sorry for the inconvenience."

FlashToo

[MrBean]

We have had the similar problems with the &(*%(**%^%$@@!  PLL

After some experiments:

- CCHR doesnt seem to work on the EVB.

- On our brand new board CCHR does work....  only once after a complete power down (Vdd<0.1) and with the PLL untouched.

- Changing CCHR after the PLL is set has no effect, even after a reset. 

-> !!!  Power down and discharge Vdd capacitors,  power up, set CCHR first, then set SYNCR.

Is this related to the "fix in next silicon" ?

The SYNSR is 0x20 after reset, 0x38 after the PLL is locked.

Bit[5] is supposed to read 0. It doesnt.

Is the documentation wrong ( bits[4-2] should be [5-3] ? ) or incomplete/incorrect about bit[5] ?

I didnt take the effort to find out, the lock bit set/reset-ing description is somewhat fuzzy.

The EVB code sets MFD=5, should be 4 for 60MHz.

Hence our first attempts on the brand new board resulted in a 50MHz PLL and therefore wrong baudrates...

Ps.:

EVB cpu:           MCF52235CAL60 datecode GAT0718

New board cpu: MCF52235CAL60 datecode QCH0815

[MrBean]

Correction: (the other EVB )

EVB cpu:           MCF52235CAL60 datecode GAA0550

New board cpu: MCF52235CAL60 datecode QCH0815

[DrSeuss]

There does appear to be an issue writing this register on the 52235. I have located an "issue" report that I am trying to figure out if it was fixed or not. In the meantime, might I suggest using one of the DMA timers for the clock source for the UART. This would allow full speed 60MHz and a prefect 250K. Set the timer to divide by 240.

[mjbcswitzerland]

Hi

Thanks for the news - at least I know that my tests were maybe not a sign that I was going mad in my old age.

Thanks for the idea about using DMA timers. I will look into this as a solution for this project and look forward to hearing results from the issue report.

Regards

Mark
www.mjbc.ch / www.uTasker.com

[mike_bdn]

Dear Mark and moderator,

my name is Miguel and I have the same problem than you. I'm trying to get de 250Kb and the only thing I get is my own foolness.

On July I think I've get it (the 250Kb) in the same way that you explain (dividing by 8 the PLL...), but when I've returned from my holidays it becomes unpossible. It seems that the pre-divider let to do this function.

Please, if you find some solution or explanation to this issue, tell me it in this forum. I think it is very important.

Thanks a lot.

Miguel

[DrSeuss]

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.

[mjbcswitzerland]

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

[DrSeuss]

Ok, I understand.

I have been able to adjust the pre-divider and effect the baud rate as specified on the the 52235 sister chip the 52223 (one with USB instead). Unfortunately, I did not bring home my Ethernet chip for the holidays.

As I can see no issue - perhaps open a Service request and send your code and I will try it on Tuesday.

As I said before, I think I was double clocking the 52235 device in the past and had no issue with the pre-divider. (Of course it was way out of spec and quite warm, but was fun!)

[DrSeuss]

There is in fact a CCHR register:

#define MCF_CLOCK_CCHR            (*(vuint8 *)(&__IPSBAR[0x120008]))

[DrSeuss]

There are no plans to increase the rated speed.

But there is lots of margin if the temp is keep in check.

[mjbcswitzerland]

Hi

The 52223 doesn't have the CCHR register (at byte address IPSBAR + 0x120008) so I don't understand how you adjusted the pre-divider, or do you mean the divider in the PLL and not between clock input and PLL input?

Thanks for the offer of looking into it. It should be easy to test using BDM - it requires generating an output clock from the bus clock or a UART speed or QSPI etc. (or a loop flashing an LED etc.) - stopping the PLL, changing the CCHR value, restarting the PLL with the same settings and seeing whether the bus frequency has changed.

My tests resulted in always the same bus frequency but if anyone could contradict this is would be great!!

By the way, if I over clock to 80MHz I have also solved the problem since 80MHz allows the perfect baud rate to be obtained. But it is out of spec. (max. 60MHz) for the M52235. I wonder whether the maximum speed will be officially increased in the near future? I did hear about people successfully testing at well over 100MHz (it was a bit of a takling point at a recent Freescale seminar), so maybe this will be a realistic solution to this project???

BTW I am also interested about the 52223 tests you talked about since there is a project planned for once the 52235 one is finished. I expect to be ordering the EVB shortly so the details may well be relevant.

Regards

Mark

[J2MEJediMaster]

I am trying to track down somebody who can help you with this.

---Tom

[mjbcswitzerland]

Hi Tom

Many thanks!!

Regards

Mark