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 (ARM adv needed)
- From: "Joe Porthouse" <jporthouse at toptech dot com>
- To: <ecos-discuss-return-35843-jporthouse=toptech dot com at ecos dot sourceware dot org>
- Cc: <ecos-discuss at ecos dot sourceware dot org>
- Date: Tue, 29 Aug 2006 17:02:20 -0400
- Subject: RE: [ECOS] Network driver problem only with larger programs (ARM adv needed)
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=toptech.com; s=MDaemon; t=1156885347; x=1158094947; 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=RTykkRiJeBw5L4Zyy0uDf83hPBh0UV/WNMJbj WxKWq0TcikqkpUdyqh07LXNBPknONhQMrDlzErYCx+yvCQqqCoczHnFHsFUFBULO G9I5Ih6lkb3YucXSpBh3PeJqKVrVwdw9JLNkxBm32D918EJOyzmSSUrVMCUo1mSF Sz+228=
- Reply-to: <jporthouse at toptech dot com>
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