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