RE: [ECOS] Network driver problem only with larger programs (cache issues?)

["Joe Porthouse" <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