CF51JM not reliable at full PLL speed

[TurboBob]

I am working on some prototypes of a new product,  and am getting wierd lockups and fail-to-start issues when the PLL is set to 48mhz (for a bus speed of 24).  This clock speed is required for USB to work,  so its important to determine the issue.

I have tried 8 mhz and 12 mhz crystals,  and the problem is essentially unchanged.  Sometimes the CPU locks up very soon after powerup,  sometimes it will run for a while.

I am using CW6.3 with ProcessorExpert.

If I reduce the clock,  the symptom goes away (not sure if its truly solved,  as testing is preliminary), but this product needs USB to be functional.

Is there some errata on this?  Does it sound familiar to anyone?

Thanks!

Bob

[TurboBob]

FLL mode works fine to full speed (alas no USB though)

anyone had this issue?

[TomE]

Is your clock switching code following the flow charts in Chapter 7 of the Reference Manual. I think Flowchart 7.10 may apply.

Can you program an output pin to some signal related to the clock (one of the timers generating a square wave), so you can monitor any frequency excursions with an oscilloscope?

Have you checked your power supplies and bypassing? The higher frequency operation may be drawing more current.

Tom

[TurboBob]

I was looking at that.  The supply bypassing was a little light,  so I tacked in a .1 ceramic and a 22uf tantalum with no change in the condition.

When running full speed from the FLL,  both internal and external,  everything runs fine.  But looking at clock stability and stuff like that makes some sense.

I am using Processor Expert with Codewarrior 6.3,  I have not double checked the clock switching sequence,  but all the other PLL equipped chips I have used in a bunch of other projects have been fine  (HC08AP, HCS08AW, HCS08JM).  It may be time to recheck the stuff I'm sure about though.

This is my first project with the CF,  I like the part,  but am getting worried.

Thanks for the suggestions,   keep them coming.

Bob Bailey

[JimDon]

Well FWIW, I use that part at 48Mhz with no issues.

The clock fail is to detect manufacuring issues.

/* * Enable the 12Mhz xtal oscillator and use the PLL * to crank it up to 48MHz. */void InitCLOCK12MHZ(void){ long counter = 0; // See chapter 7 of MCF51JMRM.pdf  // to completely understand this. // First start the 12 MHz XTAL oscillator up. // Set BDIV=0 RANGE=1,HGO=1,EREFS=1,ERCLKEN=1 MCGC2 = 0x36;    // Wait for the osc to start up. while(MCGSC_OSCINIT == 0 && counter++ < 10000)   ; if(counter > 10000) {  OSCILLATOR_Fail = 1;  return; } // Select the external ref clock (the 12 MHz oscillator). // set RDIV to divide by 8 - 12/8 = 1.5 MHz to feed the PLL // CLKS=10 RDIV=3 See 7.3.1 // Also, enable the internal 32k ref clock so RTC can use it. MCGC1 = 0x98 | MCGC1_IRCLKEN_MASK ;  // Wait for bit 3 to set and bit 2 to reset to indicate // external reference is selected. while((MCGSC & 0xC) != 0x8)  ;  // Select the PLL with a x32 multiplier to give 48MHz // PLLS=1  VDIV=8 (x32) 1.5x32=48 See Table  7.3.6 MCGC3 = 0x48;  // Wait for the PLL to be selected while(MCGSC_PLLST == 0 )  ;  // Wait for the PLL to lock. while(MCGSC_LOCK == 0)  ;  // Clear bits 6 & 7 to 0 to select the PLL output as the CPU clock. MCGC1 &= ~0xC0;  }

[TurboBob]

JimDon:

Do you write to flash in your application,  and is your application 5-volt?

Just some more thoughts.  This still bugs me.  (I'm putting a serial EEPROM on the next board layout,  anyone have some bit-bang'ed I2C code to share?)

Bob

[TomE]

Google finds some code in Linux distributions:

http://comments.gmane.org/gmane.linux.uclinux.devel/5634

Tom

[TurboBob]

Thanks for the reply.  When I said this is my first experience with the CF,  I meant "ColdFire".  But,  this is my first PLL issue also... 

When Processor Expert inits the clock,  it generates the following code.

  /*  System clock initialization */  if (*(unsigned char*)0x03FF != 0xFF) { /* Test if the device trim value is stored on the specified address */    MCGTRM = *(unsigned char*)0x03FF;  /* Initialize MCGTRM register from a non volatile memory */    MCGSC = *(unsigned char*)0x03FE;   /* Initialize MCGSC register from a non volatile memory */  }  /* MCGC2: BDIV=0,RANGE=1,HGO=1,LP=0,EREFS=1,ERCLKEN=1,EREFSTEN=0 */  setReg8(MCGC2, 0x36);                /* Set MCGC2 register */   while(!MCGSC_OSCINIT) {              /* Wait until external reference is stable */  }  /* MCGC3: DIV32=1 */  setReg8Bits(MCGC3, 0x10);               /* MCGC1: CLKS=2,RDIV=3,IREFS=0,IRCLKEN=1,IREFSTEN=0 */  setReg8(MCGC1, 0x9A);                /* Set MCGC1 register */   while(MCGSC_IREFST) {                /* Wait until external reference is selected */  }  /* MCGC3: LOLIE=1,PLLS=0,CME=0,DIV32=1,VDIV=8 */  setReg8(MCGC3, 0x98);                /* Set MCGC3 register */   /* MCGC4: ??=0,??=0,DMX32=0,??=0,??=0,??=0,DRST_DRS=0 */  setReg8(MCGC4, 0x00);                /* Set MCGC4 register */   while((MCGSC & 0x0C) != 0x08) {      /* Wait until external clock is selected as a bus clock reference */  }  /* MCGC2: BDIV=0,RANGE=1,HGO=1,LP=1,EREFS=1,ERCLKEN=1,EREFSTEN=0 */  setReg8(MCGC2, 0x3E);                /* Set MCGC2 register */   /* MCGC1: CLKS=2,RDIV=3,IREFS=0,IRCLKEN=1,IREFSTEN=0 */  setReg8(MCGC1, 0x9A);                /* Set MCGC1 register */   /* MCGC3: LOLIE=1,PLLS=0,CME=0,DIV32=0,VDIV=8 */  setReg8(MCGC3, 0x88);                /* Set MCGC3 register */   /* MCGC3: LOLIE=1,PLLS=1,CME=0,DIV32=0,VDIV=8 */  setReg8(MCGC3, 0xC8);                /* Set MCGC3 register */   while(!MCGSC_PLLST) {                /* Wait until PLL is selected */  }  /* MCGC2: LP=0 */  clrReg8Bits(MCGC2, 0x08);               while(!MCGSC_LOCK) {                 /* Wait until PLL is locked */  }  /* MCGC1: CLKS=0,RDIV=3,IREFS=0,IRCLKEN=1,IREFSTEN=0 */  setReg8(MCGC1, 0x1A);                /* Set MCGC1 register */   while((MCGSC & 0x0C) != 0x0C) {      /* Wait until PLL clock is selected as a bus clock reference */  }  /* MCGC3: CME=1 */  setReg8Bits(MCGC3, 0x20);            /* Enable Clock monitor */  

I think part of my "Lost in Space" issue may be that I had no vector for the loss of lock interrupt (the interrupt was enabled).  So I will handle that next time the unit is on the bench.  But that does not answer why it lost lock (assuming thats whats happening).

The investigation continues.

Bob

[TurboBob]

well,  I put in a vector for the loss of lock,  and thats not where its going.  I have seen it wind up in the unhandled interrupt handler,  and it also jump out into space (PC was really high) once.  Its not very repeatable.

Trying to determine how to see the interrupt source on this part.  Some days I wish I had put in the HCS08....

So,  even though the symptom occurrs when running the PLL fast,  its not a lock failure thats causing this (or so it seems)

Bob

[TurboBob]

Spent a bunch of time on this,  with the symptom being intermittant.  But always there.  I loaded the software into my JM demo board and it happens there also.  So no layout / circuit issues.   After multiple software iterations trying to track down stuff,  the symptom seemed to be getting worse,  yet the software was getting simpler.

Then,  when the software would refuse to run in 48 mhz PLL mode,  I swapped in a fresh MCU,  and its been running solid for over 24 hours in PLL mode.

The software does use the flash to save data,  and a save happens every time the software is reloaded,  as well as periodically.  So perhaps I'm breaking something with the flash routines.

I checked,  and I'm initializing the flash properly (just the FCDIV I think).

I'm using the AN3942 routines with a bugfix posted by Peg on the forum.  The fixed code is pasted below.  Perhaps the fix is wrong and I need to use the released code?

/*******************************************************************************/.if(MCU == MCF51_JM_QE_CN_AC)_Burst_Prog:               move.l  d0,d4               move.l  a1,a3               move.l  a0,d2               move.l  #(SpSubBurstEnd),a1               move.l  #(SpSubBurst),a6               bsr     DoOnStack                        move.l  a0,a1               moveq   #(mFSTAT_FACCERR+mFSTAT_FPVIOL),d0//;fix               move.b  #(mFSTAT_FCCF + mFSTAT_FCBEF),d0               move.b  d0,FSTAT               jsr     (A1)               rts.endif

Note the fix.

Does anyone have some feedback on this?  Are there better routines for this?

Thanks!!

Bob

[TurboBob · Accepted solution]

Well,  I removed the ASM flash routines and put in Flash.c and Flash.h,  which I believe are from the CF version of the badgeboard.

The new routines don't use burst mode,  but regardless,  the symptoms have subsided.  I did have to replace the CPU.  The flash array must have gotten worn out or something.  ( I saw this on several CPUs,  so it was not a defective part IMO)

I don't have any further infomation/answers  but it looks like things are working properly now.

There is an SR in the system,  as my local FAE is working with me to see if a root cause can be determined.

Just wanted to update anyone watching the thread.

Bob