This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]