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
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
