Which ARM core are you using? I had some similar weird problems with an ARM940T processor that turned out to be cache related. This was particularly tricky with the JTAG debugger. After loading the application code I needed to do the equivalent of the HAL_ICACHE_SYNC() macro to flush the instruction cache, flush and clean the data cache. Then again, your problem might be something completely different. Jay
-----Original Message----- From: Joe Porthouse [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 29, 2006 2:02 PM To: [EMAIL PROTECTED] Cc: [email protected] Subject: RE: [ECOS] Network driver problem only with larger programs (ARM adv needed) 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 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
