1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | MVME-5500 Universe II |
From: | Amit Chauhan <[email protected]> |
To: | "[email protected]" <[email protected]> |
Date: | Wed, 29 Jul 2015 12:02:08 +0530 |
Hi All, This is regarding the working of Tundra Universe II on VME based MVME-5500 CPU Board. Three of the important signals on VMEbus are Address Strobe (AS*), Data Strobes (DS0* & DS1*) and Data Acknowledgement (DTACK*). In a normal VMEbus data transfer cycle, the master asserts AS* and DS* signals. When a slave board responds with DTACK*, the master removes AS* and DS* and in turn slave also removes DTACK* thereby ending the cycle. Two common types of addressing (for slave boards)are : A16 (16-bit addressing) and A24 (24-bit addressing). On a MVME-5500 CPU,we have observed following three cases: Case-1: CPU runs under MOTload (native bootloader) and performs A24 cycle.
CPU runs under vxWorks and performs A16 cycle.
CPU runs under vxWorks and performs A24 cycle.
Case-3 (A24, vxWorks) is the most used cycle type. It is causing the problem as not every slave follows the sequence expected. Some slave boards do not use DS* to derive DTACK*. They derive DTACK* using AS* only. In such cases CPU's AS* and Slave's DTACK* remain asserted causing a deadlock. It seems the vxWorks BSP programs the Tundra Universe II chip for Case-3 in such a way that it behaves differently from Case-1 (MOTLoad) for A24 cycles. Can we make any changes somewhere in vxWorks BSP or initialization-codes for Universe II so that CPU removes AS* when it finds DTACK* asserted by slave for A24 cycles also, which it is doing for A16 cycles . Regards, Amit. |