From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <38F287EB.BE201D4@embeddededge.com> Date: Mon, 10 Apr 2000 22:03:23 -0400 From: Dan Malek MIME-Version: 1.0 To: Jeff Millar CC: Marcus Sundberg , Pavel Roskin , "Wohlgemuth, Jason" , linuxppc-embedded@lists.linuxppc.org Subject: Re: Software Emulation Exception... References: <38EE0267.FB881499@embeddededge.com> <38F200CF.B4A07187@embeddededge.com> <001001bfa35e$cb0021a0$0201a8c0@home> Content-Type: text/plain; charset=us-ascii Sender: owner-linuxppc-embedded@lists.linuxppc.org List-Id: Jeff Millar wrote: > .... So, is it a > problem with the RPX board or the Sandisk? Like I said before. I can't guess, and neither should you. The fact is the software emulation trap is caused by fetching an instruction that can't be properly decoded. We need to determine what it fetched and where that came from. These are some fundamental engineering skills we are trying to use here. Why aren't we using them? The PCMCIA interfaces have their timing requirements. On the 8xx, these are all very programmable. Look at the card specifications and the values programmed. Do they seem reasonable? Don't simply run maximum, excessively long timing on the PCMCIA. This can be just as bad on some cards or other external devices as running too fast. Attach a logic analyzer. Does the timing on the 8xx bus look reasonable? Use one of the GPIO pins to trigger the analyzer when you trap the fault (as early as possible). Look at the bus signals. What really happened? -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/