From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7954 invoked by alias); 29 Aug 2006 21:02:43 -0000 Received: (qmail 7933 invoked by uid 22791); 29 Aug 2006 21:02:42 -0000 X-Spam-Check-By: sourceware.org Received: from Unknown (HELO mail.toptech.com) (206.104.148.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Aug 2006 21:02:31 +0000 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= Received: from jporthousexp2 by toptecheurope.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.6) with ESMTP id 05-md50000003284.msg for ; Tue, 29 Aug 2006 17:02:27 -0400 Reply-To: From: "Joe Porthouse" To: Cc: Date: Tue, 29 Aug 2006 21:02:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20060814200410.GU29570@lunn.ch> X-HashCash: 1:20:060829:md50000003284::BPCRTM2d0ZXj8vH9:00002bN2 X-Spam-Processed: mail.toptech.com, Tue, 29 Aug 2006 17:02:27 -0400 (not processed: message from valid local sender) X-MDRemoteIP: 172.16.65.68 X-Return-Path: jporthouse@toptech.com X-Envelope-From: jporthouse@toptech.com X-MDaemon-Deliver-To: ecos-discuss@ecos.sourceware.org Message-ID: X-MDAV-Processed: mail.toptech.com, Tue, 29 Aug 2006 17:02:27 -0400 X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: RE: [ECOS] Network driver problem only with larger programs (ARM adv needed) X-SW-Source: 2006-08/txt/msg00266.txt.bz2 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