* [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).