Byte alignment can be a possible cause, but 72cc is an even address. Still have no clue. Thanks for any help.
On Thu, May 19, 2011 at 12:01 AM, Xiaohui Liu <[email protected]> wrote: > Hi, > > It seems the only difference is the following: > ne->flags = 0; > 72c8: ce 43 05 00 mov.b #0, 5(r14) ;r3 As==00 > ne->flags = 5; > 72c8: fe 40 05 00 mov.b #5, 5(r14) ;#0x0005 > 72cc: 05 00 > > But I'm really lost on why this can cause the mote to crash. Please help. > > On Wed, May 18, 2011 at 9:08 PM, Xiaohui Liu <[email protected]> wrote: > >> 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 <[email protected]> wrote: >> >>> >>> >>> On Tue, May 17, 2011 at 6:50 PM, Xiaohui Liu <[email protected]> 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 <[email protected]>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 >>>> [email protected] >>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>> >>> >>> >>> >>> -- >>> Eric B. Decker >>> Senior (over 50 :-) Researcher >>> >>> >>> >> >> >> -- >> -Xiaohui Liu >> > > > > -- > -Xiaohui Liu > -- -Xiaohui Liu
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
