This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: Network driver problem only with larger programs (cache issues?)
- From: "Joe Porthouse" <jporthouse at toptech dot com>
- To: <ecos-discuss-return-35965-jporthouse=toptech dot com at ecos dot sourceware dot org>
- Cc: <ecos-discuss at ecos dot sourceware dot org>
- Date: Thu, 31 Aug 2006 16:38:18 -0400
- Subject: RE: [ECOS] Network driver problem only with larger programs (cache issues?)
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=toptech.com; s=MDaemon; t=1157056703; x=1158266303; q=dns; h=DomainKey-Signature: Received:Reply-To:From:To:Cc:Subject:Date:Organization: MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To: Thread-Index:Message-ID; b=evnvQwpuYxZCSIWCaZQdXwFcH9i5xWSLL7gxq ONcfqux9hcz9H6lizzitQZ75CO2mSosV+YpdH+uC3NzXh+6D8sZ5aSqnNK24PiH9 q2RFB5JJiMRcdzQBV0AsmdjlaT1ITNNQjmEAYC6jPMseRreBkMSUJWAvCq2zkFH5 MoOWKw=
- Reply-to: <jporthouse at toptech dot com>
Ported most of the sdram0.cxx to my platform and it works without any
errors.
Also ran the cache.c and it ran as expected.
Upon a closer look the execution, the incorrect jump is always occurring
from an address (in the narrow of 0x00100500-0x0x00100700) to an unrelated
address (always in the very narrow range of 0x0010032c-0x00100340). While
adding and removing code I also noticed that there was no logic to the
particular function or machine instruction at either address, the jump would
still occur at the same address.
Running the application on the same target, but with the Ethernet controller
selects disconnected did not seem to have the problem. (Asserts locked
things up later in the execution, so this was not conclusive). If I skipped
all calls to the Ethernet init/constructors, the problem also did not occur
on either hardware platform, but it also skipped the memory area where the
problem was.
Since the problem seemed to be memory I rebuilt the application with only
changing the following in the target.ld file:
.text 0x00008000 : // start of application at 32K address
To
.text 0x00200000 : // start of application at 2Meg address
To skip over the "bad" area, AND IT WORKED!!! I will be doing a longer test
this evening.
Does this indicate that the generated code is good, and I should be looking
exclusively to the hardware for the problem? Any ideas on further tracking
this down?
Something else interesting is that the 91C111 Ethernet controller is at
0x08000300-30F. I wonder if there is some issue between these two addresses
on my target?
Here's the latest trace of the same problem.
-00013 DBRA 03 00000000 00000000
-00012 00 00000000 00000000
-00011 UNDEF 00 00000000 00000000
-00010 00 00000000 00000000
-00009 FIQ 00 00000000 00000000
-00008 IBRA 03 00100574 00100664
00100664 e92dd8f0 STMFD SP!,{R4-R7,R11,R12,LR,PC}
00100574 e5842000 STR R2,[R4]
00100578 159c3000 LDRNE R3,[R12]
0010057C e584a00c STR R10,[R4,#00c]
-00007 DBRA 01 00000000 00000000
-00006 DBRA 03 00000000 00000000
-00005 00 00000000 00000000
-00004 UNDEF 00 00000000 00000000
-00003 00 00000000 00000000
-00002 SWI 00 00000000 00000000
-00001 IBRA 00 00100120 00100580
00100580 e5814018 STR R4,[R1,#018]
TRIG DBRA 00 00000000 00000000
PC = 0x00100340
Joe Porthouse
Toptech Systems, Inc.
Longwood, FL 32750
-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andrew Lunn
Sent: Thursday, August 31, 2006 2:46 AM
To: Joe Porthouse
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Network driver problem only with larger programs (cache
issues?)
On Thu, Aug 31, 2006 at 12:18:36AM -0400, Joe Porthouse wrote:
> Ok, I'm positive I'm going nuts now.... Code seems good, if I can only
get
> the processor to correctly execute it.
>
> Started seeing the code lock up after 10-30 minutes without a JTAG
attached
> so I started to look further into the possible cache issues.
There was once a problem with the EBSA285 setup of the SDRAM
controller. The controller had been initialised for 1/2 the actual
memory. This resulted in the top address line being left to
float. Most of the time it floated one way, but occassionally, it
floated the other way, and so it seemed to forget things.....
See if you can make packages/hal/arm/ebsa286/current/tests/sdram0.cxx
work on your target. Also try running the
packages/hal/common/current/tests/cache.c
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss