Thank you very much. I find the following function is causing the mote to crash. Everything works find if ne->flags is set to 0, and the mote crashes if it is set to 5 (the only change). This is the weirdest bug I have even seen and I'm not familiar with assembly code. Please help. I use "msp430-objdump -d --source main.exe" and below is the code snippet and their respective assembly.
void initNeighborIdx(uint8_t i, am_addr_t ll_addr) { neighbor_table_entry_t *ne; ne = &NeighborTable[i]; ne->ll_addr = ll_addr; ne->lastseq = 0; ne->rcvcnt = 0; ne->failcnt = 0; ne->flags = 0; ne->inage = MAX_AGE; ne->inquality = 0; ne->eetx = 0; } 0000729c <LinkEstimatorP__initNeighborIdx>: 729c: 4d 4f mov.b r15, r13 ; 729e: 0c 4e mov r14, r12 ; 72a0: 7f f3 and.b #-1, r15 ;r3 As==11 72a2: 0f 5f rla r15 ; 72a4: 0f 5f rla r15 ; 72a6: 0f 5f rla r15 ; 72a8: 0f 5f rla r15 ; 72aa: 0f 5f rla r15 ; 72ac: 4e 4d mov.b r13, r14 ; 72ae: 0e 5e rla r14 ; 72b0: 0e 8f sub r15, r14 ; 72b2: 0f 4e mov r14, r15 ; 72b4: 3e 50 6e 19 add #6510, r14 ;#0x196e 72b8: 8f 4c 6e 19 mov r12, 6510(r15); 72bc: ce 43 02 00 mov.b #0, 2(r14) ;r3 As==00 72c0: ce 43 03 00 mov.b #0, 3(r14) ;r3 As==00 72c4: ce 43 04 00 mov.b #0, 4(r14) ;r3 As==00 72c8: ce 43 05 00 mov.b #0, 5(r14) ;r3 As==00 72cc: fe 40 06 00 mov.b #6, 6(r14) ;#0x0006 72d0: 06 00 72d2: ce 43 07 00 mov.b #0, 7(r14) ;r3 As==00 72d6: 8e 43 08 00 mov #0, 8(r14) ;r3 As==00 72da: 30 41 ret void initNeighborIdx(uint8_t i, am_addr_t ll_addr) { neighbor_table_entry_t *ne; ne = &NeighborTable[i]; ne->ll_addr = ll_addr; ne->lastseq = 0; ne->rcvcnt = 0; ne->failcnt = 0; ne->flags = 5; ne->inage = MAX_AGE; ne->inquality = 0; ne->eetx = 0; } 0000729c <LinkEstimatorP__initNeighborIdx>: 729c: 4d 4f mov.b r15, r13 ; 729e: 0c 4e mov r14, r12 ; 72a0: 7f f3 and.b #-1, r15 ;r3 As==11 72a2: 0f 5f rla r15 ; 72a4: 0f 5f rla r15 ; 72a6: 0f 5f rla r15 ; 72a8: 0f 5f rla r15 ; 72aa: 0f 5f rla r15 ; 72ac: 4e 4d mov.b r13, r14 ; 72ae: 0e 5e rla r14 ; 72b0: 0e 8f sub r15, r14 ; 72b2: 0f 4e mov r14, r15 ; 72b4: 3e 50 6e 19 add #6510, r14 ;#0x196e 72b8: 8f 4c 6e 19 mov r12, 6510(r15); 72bc: ce 43 02 00 mov.b #0, 2(r14) ;r3 As==00 72c0: ce 43 03 00 mov.b #0, 3(r14) ;r3 As==00 72c4: ce 43 04 00 mov.b #0, 4(r14) ;r3 As==00 72c8: fe 40 05 00 mov.b #5, 5(r14) ;#0x0005 72cc: 05 00 72ce: fe 40 06 00 mov.b #6, 6(r14) ;#0x0006 72d2: 06 00 72d4: ce 43 07 00 mov.b #0, 7(r14) ;r3 As==00 72d8: 8e 43 08 00 mov #0, 8(r14) ;r3 As==00 72dc: 30 41 ret On Wed, May 18, 2011 at 2:11 AM, Eric Decker <cire...@gmail.com> wrote: > > > On Tue, May 17, 2011 at 6:50 PM, Xiaohui Liu <whu...@gmail.com> wrote: > >> Hi, >> >> I'm meeting the same issue again and trying to use "nm". How do I let "nm" >> display the symbols only in bss section and order by their address in >> non-decreasing fashion? This way, I can see what symbols are near the one >> I'm tracking. Thanks. >> > > When you don't know how to use a tool the first thing you should try is > reading the manual. > > I don't see a reference to what processor you are using (or platform which > then implies the processor), but if memory serves (yeah right), you are > using a telosb which is msp430f1611 based. > > So you want to try > > man msp430-objdump > man msp430-nm > > You can also do: > > msp430-objdump --help > msp430-nm --help > > > more below: > > >> >> On Fri, Aug 20, 2010 at 6:16 PM, Philip Levis <p...@cs.stanford.edu>wrote: >> >>> >>> On Aug 20, 2010, at 7:22 AM, Xiaohui Liu wrote: >>> >>> > Actually, I'm trying to change 4 bit link estimation (4bitle) to >>> estimate some link delay related information. At the beginning, 4bitle is >>> working fine. However, after I add the blue fields (nothing else), 4bitle >>> seems to malfunction. Hope this helps clarify my question. >>> >>> You need to be more precise. "Malfunction" is not helpful when it comes >>> to debugging. >>> >>> Sorry to say this, but you're going about debugging this all wrong. >>> You're confusing a symptom (when you change the structure) with a diagnosis >>> (what's going wrong in the program). This kind of debugging is just throwing >>> darts in the dark: it doesn't get you to the bottom of the problem. >>> >>> There are two possibilities: >>> >>> 1) More likely: there is a memory access bug in your code. When you >>> change the structure definition, the compiler places the differently sized >>> structure in a different place in memory. E.g., next to the memory with the >>> bug. One way to help diagnose this is to examine what variables are near the >>> structure in the two different executables (nm, objdump, etc.). >>> >> > To see the machine code interspersed with some semblance of the source code > (take with a grain of salt, doesn't always get it right): > > msp430-objdump -d --source main.exe > > > To see a numerically sorted symbol table of the image: > > msp430-nm -n main.exe > > >> >>> 2) Much less likely: there is a compiler bug on access to the structure. >>> The way to diagnose this is to look at the generated assembly. >>> >>> Effective diagnosis requires, in both cases, a clear understanding of >>> what the memory access error is and how it manifests. >>> >>> Regardless, chances are this bug has nothing to do with nesC, and is >>> really just a low-level C bug. That is, unless nesc1 is doing something >>> weird (very unlikely). You can check this by looking at app.c. >>> >>> Phil >> >> >> >> >> -- >> -Xiaohui Liu >> >> _______________________________________________ >> Tinyos-help mailing list >> Tinyos-help@millennium.berkeley.edu >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> > > > > -- > Eric B. Decker > Senior (over 50 :-) Researcher > > > -- -Xiaohui Liu
_______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help