Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: FW: MVME162 Bug in system clock
From: johill@lanl.gov (Jeff Hill)
To: "EPICS-tech-talk" <tech-talk@aps.anl.gov>
Date: Wed, 4 Aug 1999 14:34:43 -0600
All,

This may be of interest to persons that are using the Motorola MVME162.

Jeff

> -----Original Message-----
> From: the vxWorks Users Group Exploder [mailto:vxwexplo@lbl.gov]
> Sent: Wednesday, August 04, 1999 7:29 AM
> To: vxworks_users@csg.lbl.gov
> Subject: MVME162 Bug in system clock
>
>
> Submitted-by owner-vxwexplo-process  Wed Aug  4 06:28:55 1999
> Submitted-by: David Abbott <abbottd@jlab.org>
>
>
> Hello vxWorks users,
>      I came across what looks to be a very long standing bug in the
> BSP for the Motorola MVME162 single board computer. I thought I would
> pass the info along to anyone who cares.
>
>     Our problem ocurred when we were attempting to periodically
> write some status information to a file on an NFS mounted disk. This
> was done every 15 minutes or so. To help keep track of the files,
> we created a filename containing a time/date stamp in its name.
> We noticed that over the course of a day or two the time/date stamps
> were getting further and further out of sync with the UNIX file
> server's time (almost an hour behind over a 24 hour period).
>
>    A little investigation into the BSP found that the vxWorks system
> clock is working off one of the tick timers in the MCChip on the MV162.
> These timers rely on prescaling the processor's clock speed down to
> 1 MHz. Hence there is a Prescale Clock Adjust Register on the Chip that
> must be programmed correctly. There is also a CPU Version Register
> that is read only containing information about the the Processor type,
> and the presence of SCSI, ethernet, and VME interface chips.
>
>   In syslib.c (sysHwInit), the Version register is checked and the
> Prescale Clock Adjust Register is set for either a 25MHz CPU or a 33 MHz
> CPU (see code snippet):
>
>     if (*MCC_VERSION_REG & 0x01)	/* check clock speed */
> 	{
>         *MCC_PRESCALE_CLK_ADJ  = 256 - 33;	/* for 33 MHz board */
>         *MCC_PRESCALE          = 256 - 33;
> 	*MCC_BUS_CLK_REG       = 33;
> 	}
>     else
> 	{
> 	*MCC_PRESCALE_CLK_ADJ  = 256 - 25;	/* for 25 MHz board */
> 	*MCC_PRESCALE          = 256 - 25;
> 	*MCC_BUS_CLK_REG       = 25;
> 	}
>
> The problem is that about 4 years ago Motorola introduced the MV162 FX and
> LX series of VME CPUs which run at 25MHz or 32MHz. So if you have a 32MHz
> version of a MV162 the Prescale Clock Adjust Register is set incorrectly
> and the whole vxWorks system clock time base is off by a factor 32/33.
> Hence, when 1 realtime second has passed the vxWorks OS only
> thinks .97 sec
> have passed.
>
>    For most of our applications a 3% effect is not an issue, but if folks
> are relying accurate time based applications the fix is easy. Just change
> the above code in sysLib.c replacing the 33 for 32.
>
>   A couple of additional notes: First this does not affect the MV167 BSP
> as that board really does run at 33MHz. Also I have noticed that even with
> the latest BSPs distributed with Tornado II and vxWorks 5.4 the
> bug is still
> there.
>
>
>
> ---------------------------------------------------------
> David Abbott                      Jefferson Lab
> Data Acquisition Group            MS 12H
> EMAIL: abbottd@jlab.org           12000 Jefferson Ave.
> Tel: (757) 269-7190               Newport News, VA  23606
> FAX: (757) 269-5800
> ---------------------------------------------------------
>
>
> **********
>
>     This is a user group mailing list for vxWorks related topics
>     Mail articles to vxwexplo@lbl.gov for 'explosion'
>       Include the word VxWorks or Tornado to penetrate SPAM filters
>       edit off the trailer to avoid bounce filters
>     Send subscription requests & comments to vxwexplo-request@lbl.gov
>



Navigate by Date:
Prev: FW: GCC generates floating point code on its own for PPC. Jeff Hill
Next: RE: Channel Access Gateway software Jeff Hill
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: FW: GCC generates floating point code on its own for PPC. Jeff Hill
Next: Array Information Noboru Yamamoto
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·