public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Network driver problem only with larger programs...
@ 2006-08-14 20:01 Joe Porthouse
  2006-08-14 20:04 ` Andrew Lunn
  0 siblings, 1 reply; 3+ messages in thread
From: Joe Porthouse @ 2006-08-14 20:01 UTC (permalink / raw)
  To: ecos-discuss


I've been stuck here for a while, so any advice would be greatly
appreciated.

Working with my small application, I am successfully able to manually
configure the SMSC 91C111 driver from my application and everything seems to
work without a problem (ping and socket connections).

When I attempt to do the same in my much larger application, execution only
gets a few lines into my main and locks up.  The "network interface
initialization" call in my application is not even called yet.

If I ifdef out most of the code in my main (causing many functions to be
excluded from the .bin file), the lockup no longer occurs.

The "network initialization" that eCos does seems to be completing
successfully from the debug messages I see, but after a timer tick,
alarm_thread(), do_timeout() and ip_reass(), the execution gets hung up in
an illegal memory reference.

Init device '/dev/ttydiag'
Init tty channel: 288eac
Init device '/dev/haldiag'
HAL/diag SERIAL init
Network stack using 69632 bytes for misc space
                    69632 bytes for mbufs
                    139264 bytes for mbuf clusters
[cyg_net_init] Init: mbinit(0x00000000)
[cyg_net_init] Init: cyg_net_init_devs(0x00000000)
Init device 'lan91cxx_eth0'
[cyg_net_init] Init: loopattach(0x00000000)
[cyg_net_init] Init: ifinit(0x00000000)
[cyg_net_init] Init: domaininit(0x00000000)
[cyg_net_init] Init: cyg_net_add_domain(0x00288b90)
New domain internet at 0x00000000
[cyg_net_init] Init: cyg_net_add_domain(0x00288620)
New domain route at 0x00000000
[cyg_net_init] Init: call_route_init(0x00000000)
[cyg_net_init] Done
1
(something bad happens here...)

My instinct says I am exceeding some memory limit somewhere (stack, heap,
code space, my sanity).  I have increased the main() stack size from 8192 to
32,000 with no luck.  I have a total of 64MB of SDRAM with a program image
size of about 3.2 MB.  Application is run from RAM.  I am not using RedBoot,
but compiling up eCos and my application into a single binary image.

Joe Porthouse
Toptech Systems, Inc.
Longwood, FL 32750



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [ECOS] Network driver problem only with larger programs...
  2006-08-14 20:01 [ECOS] Network driver problem only with larger programs Joe Porthouse
@ 2006-08-14 20:04 ` Andrew Lunn
  2006-08-29 21:02   ` [ECOS] Network driver problem only with larger programs (ARM adv needed) Joe Porthouse
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Lunn @ 2006-08-14 20:04 UTC (permalink / raw)
  To: Joe Porthouse; +Cc: ecos-discuss

On Mon, Aug 14, 2006 at 04:01:05PM -0400, Joe Porthouse wrote:
> 
> I've been stuck here for a while, so any advice would be greatly
> appreciated.
> 
> Working with my small application, I am successfully able to manually
> configure the SMSC 91C111 driver from my application and everything seems to
> work without a problem (ping and socket connections).
> 
> When I attempt to do the same in my much larger application, execution only
> gets a few lines into my main and locks up.  The "network interface
> initialization" call in my application is not even called yet.
> 
> If I ifdef out most of the code in my main (causing many functions to be
> excluded from the .bin file), the lockup no longer occurs.
> 
> The "network initialization" that eCos does seems to be completing
> successfully from the debug messages I see, but after a timer tick,
> alarm_thread(), do_timeout() and ip_reass(), the execution gets hung up in
> an illegal memory reference.
> 
> Init device '/dev/ttydiag'
> Init tty channel: 288eac
> Init device '/dev/haldiag'
> HAL/diag SERIAL init
> Network stack using 69632 bytes for misc space
>                     69632 bytes for mbufs
>                     139264 bytes for mbuf clusters
> [cyg_net_init] Init: mbinit(0x00000000)
> [cyg_net_init] Init: cyg_net_init_devs(0x00000000)
> Init device 'lan91cxx_eth0'
> [cyg_net_init] Init: loopattach(0x00000000)
> [cyg_net_init] Init: ifinit(0x00000000)
> [cyg_net_init] Init: domaininit(0x00000000)
> [cyg_net_init] Init: cyg_net_add_domain(0x00288b90)
> New domain internet at 0x00000000
> [cyg_net_init] Init: cyg_net_add_domain(0x00288620)
> New domain route at 0x00000000
> [cyg_net_init] Init: call_route_init(0x00000000)
> [cyg_net_init] Done
> 1
> (something bad happens here...)
> 
> My instinct says I am exceeding some memory limit somewhere (stack, heap,
> code space, my sanity).  I have increased the main() stack size from 8192 to
> 32,000 with no luck.  I have a total of 64MB of SDRAM with a program image
> size of about 3.2 MB.  Application is run from RAM.  I am not using RedBoot,
> but compiling up eCos and my application into a single binary image.

Try enabling asserts and stack checking in the infra package. It might
tell you something.

     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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: [ECOS] Network driver problem only with larger programs (ARM adv needed)
  2006-08-14 20:04 ` Andrew Lunn
@ 2006-08-29 21:02   ` Joe Porthouse
  0 siblings, 0 replies; 3+ messages in thread
From: Joe Porthouse @ 2006-08-29 21:02 UTC (permalink / raw)
  To: ecos-discuss-return-35843-jporthouse=toptech.com; +Cc: ecos-discuss

I enabled asserts and stack checking and the problem stopped.  I then turned
off asserts and stack checking and the problem did not reoccur...until
today.

Now with asserts and stack checking enabled I get no errors, but the
execution still gets hung up in the cyg_do_net_init() call from the
cyg_hal_invoke_constructors() routine.

Using breakpoints and the traceback feature of my JTAG I can see exactly
where things go wrong, but don't know why.

All constructors get called correctly until the cyg_do_net_init is called.
When this occurs execution gets two instructions into the procedure and then
jumps into the middle of the cyg_timeout() function where it enters an
endless loop.

Checking addresses and registers everything looks ok (to me).  I have even
tried this on three different pieces of hardware.  I am at a complete loss
on why this is occurring.  I can step through the same piece of code in a
small program and execution occurs as expected.

Any advice would be greatly appreciated.

Trace leading up to the offending instruction looks like:
       hal_misc.c Line 202 (cyg_hal_invoke_constructors)
       202               (*p) ();
       000E937C e1a0e00f  MOV       LR,PC
  TRIG 000E9380 e414f004  LDR       PC,[R4],#-004   // jump from here
       001007C8 e52de004  STR       LR,[SP,#-004]!  // to here, ok!

Registers at this point are:
R0  00008000
R1  00000004
R2  003d940c
R3  0037d0fc
R4  0037d85c <- constructor table address, good
R5  0037d848
R6  0b0b0b0b
R7  0b0b0b0b
R8  00000000
R9  a0003000
R10 0010032c
R11 0037f00c
R12 003d940c
SP  0037eff8
LR  000e9384
PC  001007cc <- PC jumped to correct address, now at 2nd address
CPSR 200000d3
SPSR 000000d3

Execution should follow the listing as:
_GLOBAL__I.52100_cyg_do_net_init: 
001007C8 e52de004   STR       LR,[SP,#-004]!  <- jumped here ok.
001007CC e3a01ccb   MOV       R1,#0000cb00    <- PC now here.
001007D0 e2811084   ADD       R1,R1,#00000084
001007D4 e3a00001   MOV       R0,#00000001
001007D8 e49de004   LDR       LR,[SP],#004
001007DC eafffff1   B        _Z41__static_initialization_and_destruction_0ii

But on the next step execution jumps into timeout() at address 00100330:
262                     cyg_uint32 
263                     timeout(timeout_fun *fun, void *arg, cyg_int32
delta) 
264                     { 
cyg_timeout: 
00100308 e1a0c00d   MOV       R12,SP
0010030C e92dddf0   STMFD     SP!,{R4-R8,R10-R12,LR,PC}
00100310 e24cb004   SUB       R11,R12,#00000004
00100314 e1a07002   MOV       R7,R2
00100318 e1a08000   MOV       R8,R0
0010031C e1a0a001   MOV       R10,R1
265                         int i; 
266                         timeout_entry *e; 
267                         cyg_uint32 stamp; 
268                      
269                         // this needs to be atomic - recursive calls
from the alarm 
270                         // handler thread itself are allowed: 
271                         int spl = cyg_splinternal(); 
00100320 ebfffd88   BL        cyg_splinternal
274                         for (e = _timeouts, i = 0;  i < NTIMEOUTS;  i++,
e++) { 
00100324 e59f4060   LDR       R4,0010038c
272                      
273                         stamp = 0;  // Assume no slots available 
00100328 e3a05000   MOV       R5,#00000000
0010032C e1a06000   MOV       R6,R0
00100330 e1a02005   MOV       R2,R5       <- WHY ARE WE HERE NOW???
275                             if ((e->flags & CALLOUT_PENDING) == 0) { 
00100334 e5943014   LDR       R3,[R4,#014]
00100338 e2822001   ADD       R2,R2,#00000001
0010033C e3130004   TST       R3,#00000004
00100340 0a000006   BEQ       cyg_timeout+58
00100344 e3520007   CMP       R2,#00000007
00100348 e2844018   ADD       R4,R4,#00000018
0010034C dafffff8   BLE       cyg_timeout+2c
282                             } 
283                         }


Joe Porthouse
Toptech Systems, Inc.
Longwood, FL 32750



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-08-29 21:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-08-14 20:01 [ECOS] Network driver problem only with larger programs Joe Porthouse
2006-08-14 20:04 ` Andrew Lunn
2006-08-29 21:02   ` [ECOS] Network driver problem only with larger programs (ARM adv needed) Joe Porthouse

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).