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