mcf52233 clock off by 20% with CW10 (sometimes)

[alager]

We have a mature product that was developed on CW7.  We've ported it over to CW10.4, and have found that some boards, identical in measured 25Mhz xtal input, are running about 20% slower.  40Mhz instead of 50Mhz.

This is causing the uart baud rate calculations to be wrong among other things.

Below is the pll initialization function.  I've checked the LOCK bit in SYNSR and it indicates that the PLL is locked.

void 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 10 to acheive system clock of 50Mhz --> MCF_CLOCK_SYNCR_MFD(3)

  */

  MCF_CLOCK_SYNCR = MCF_CLOCK_SYNCR_MFD(3) | MCF_CLOCK_SYNCR_CLKSRC| MCF_CLOCK_SYNCR_PLLMODE | MCF_CLOCK_SYNCR_PLLEN ;

  while (!(MCF_CLOCK_SYNSR & MCF_CLOCK_SYNSR_LOCK))

  {

  }

}

I've tried erasing the chip completely and then re-programming to no avail.  If I load up one of the S19 files that was generated with CW7, then there are no issues with any of the boards.

chip markings are different only in the third line:

good: qaaq932

bad: qea1042

Any ideas on how to correct this would be greatly appreciated!

Aaron

[alager]

Thank you both for your input.  Yes, I have both old and new silicon, and I was putting in the wrong divider value.  The old silicon was masking the issue, while the new silicon did exactly what I told it to do.

Aaron

[TomE]

That's an interesting problem.

I'll try and simplify and summarise. Please correct me if I've got anything wrong.

The boards have 25MHz Crystals on them, not hybrid oscillator packs.

You've measured the crystal frequency with a meter or an oscilloscope and verified that they are all oscillating at 25MHz.

You have two different apparent revisions of the CPU, one marked "qaaq932" and the other ones marked "qeq1042".

Both revisions work OK when loaded with code generated by CW7. When loaded with the CW10.4 code, all of the "qea1042" ones run slow.

Here's some other things to try.

Is it an obviously ANALOG or DIGITAL problem? What frequency are they running at exactly and is it stable? If it is stable, and an exact integer multiple of the expected frequency then w can look for register or software changes. If it is not an exact multiple, varying with temperature or capacitance or if there's a lot of "jitter" then it would look like an analog/oscillator/PLL problem of some sort.

See if the "slow" ones still run slow WHILE you're measuring the oscillator frequency with an oscilloscope. It is possible the crystal isn't running at the right speed normally, but the extra loading of the probe makes it run at the right speed.

Get the Mask Revision numbers of the chips from "12.3.3.3 Chip Identification Register (CIR)". That's easier than trying to find a document that explains "qaaq" and "qeq" markings. Then again, the Reference Manual says the "PRN" is a number without referencing the actual Mask values, and the Errata lists MCF5223x masks 2M23E, 3M23E and an "MCF5223xA" without a mask version, but doesn't say what the PRN is for these.

This document lists these numbers as a "Trace/Date code" and has as tested examples QAA1112, QAC1112 and QAD1112

http://www.freescale.com/docs/pcn_attachments/15078_Kirin_2e_4M23E_Mask_Revision_Qualification_resul...

So the letters are the lab it was made at and the numbers are the date code, probably Year and Week.

This document lists a "4M23E" mask released in March 2012.

http://cache.freescale.com/files/shared/doc/pcn/PCN15078.htm

But your chips are probably 2009 (32nd week) and 2010 (42nd week). This document announces the release of the 3M23E mask somewhere between Nov 2009 and Feb 2010

http://cache.freescale.com/files/shared/doc/pcn/PCN13905.htm

It looks like I went through this previously here:

https://community.freescale.com/message/300686#300686

What are ALL the markings on the packages? The second line might be the mask number.

Anyhow, one of the above documents says 3M23E fixed a bug where "Clock Control High Register (CCHR) Not Writable". That's CCHR with a default value of "4" which divides the crystal by "5". Are you generating any code that is trying to change that value as it won't work. Luckily you included enough clock setting code and...

Bingo, we have a Winner!

> MCF_CLOCK_CCHR =0x05; // The PLL pre divider - 25MHz / 5 = 5MHz

If you read the manual you'll see that setting that to FOUR divides by FIVE, so setting it to FIVE divides by SIX. So you should be running at exactly 41.67MHz. Had you measured this exact 5:6 ratio difference it might have pointed to this divider and this register.

Read the register back on the "good" and "bad" units and see what it is. I'll bet the "09" ones are 2M23E parts and you'll read "4" and the "10" ones are 3M23E parts and you'll read "5".

So the old chips were hiding this programming bug.

Your CW7 code either didn't set this register at all or set it to the right value or maybe tested the PRN and did something different on the different mask values.

Which one was it?

Tom

[mjbcswitzerland]

Aaron

I came to the same conclusion at http://www.utasker.com/forum/index.php?topic=1853.msg6707#msg6707

Note that the uTasker macros are more refined and so the error doesn't ocurr with original code.

Also note that the chip errate involved was originally reported in 2006 : https://community.freescale.com/message/13535#13535

but took a couple of years before it made its way into the errate document.

Regards

Mark