EPICS Home

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  2021  2022  2023  2024  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  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: FW: MVME162 Bug in system clock
From: [email protected] (Jeff Hill)
To: "EPICS-tech-talk" <[email protected]>
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:[email protected]]
> Sent: Wednesday, August 04, 1999 7:29 AM
> To: [email protected]
> Subject: MVME162 Bug in system clock
>
>
> Submitted-by owner-vxwexplo-process  Wed Aug  4 06:28:55 1999
> Submitted-by: David Abbott <[email protected]>
>
>
> 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: [email protected]           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 [email protected] 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 [email protected]
>



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  2021  2022  2023  2024 
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  2021  2022  2023  2024