I looked into this a little bit and it seems like this bug was
introduced when we put code that sets the white bit in the metadata.
The problem is in packetReceiveDone(), we are checking if the radio is
in RECEIVED_STATE before setting it to RECEIVED_STATE. The radio would
be in RX_STATE and discard the packet. Here is the relevant code
snippet:
void enterReceivedState() {
radioState = RECEIVED_STATE;
}
void packetReceiveDone() {
message_t* pBuf;
uint16_t snr;
atomic {
if (radioState != RECEIVED_STATE) {
return;
}
....
post signalPacketReceived();
enterReceivedState();
}
Phil, you own this code so you should decide how to fix this problem.
BTW, I did not get the out of bound error that John found - maybe I
did not run the test long enough...
Thanks.
- om_p
On Mon, Jun 2, 2008 at 4:03 PM, John Regehr <[EMAIL PROTECTED]> wrote:
> Ok, we found some mica2s and put Oscilloscope on them after hacking
> CC1000SendReceiveP.nc to check for count going out of bounds. It is
> definitely going out of bounds at line 501.
>
> John
>
>
>
> On Sun, 1 Jun 2008, John Regehr wrote:
>
>> We think we have found a problem in the CC1000 receive-side code that is
>> perhaps related to the behavior described here.
>>
>> The suspected culprit is at line 501 of CC1000SendReceiveP.nc which looks
>> like this:
>>
>> ((uint8_t *)rxBufPtr)[count++] = nextByte;
>>
>> We think that count is going out of bounds, leading to RAM corruption.
>> To test this, introduce some code just before this line that is something
>> like
>>
>> if (count>=sizeof(message_t)) { ... blink LEDs in infinite loop ... }
>>
>> Confirmation that this check fails (or not) would be useful to us.
>>
>> We'd do this ourselves but we seem to have very few mica2s sitting
>> around.
>>
>> The root problem may be a failure to clear count at an appropriate time.
>>
>> John
>>
>>
>>
>>
>> On Sun, 1 Jun 2008, Philip Levis wrote:
>>
>>>
>>> On May 30, 2008, at 1:22 PM, Dima Kogan wrote:
>>>
>>>> I can confirm this. My CC1000-based motes work fine with the 2.0.2
>>>> release but crash with the latest cvs. I run a modified BlinkToRadio
>>>> to test, with one node only transmitting and the other node only
>>>> receiving. The transmitting node works ok. The receiving node seems
>>>> to crash. As a test, I turn on an LED in Boot.booted() and don't
>>>> turn it off in any part of the code. This LED blinks or turns off at
>>>> various times on the transmitted node, which indicates that the mote
>>>> is
>>>> rebooting. ALso, the first packet from the transmitter is always
>>>> received properly, with the erroneous behavior starting with the
>>>> second
>>>> packet.
>>>
>>> There have only been a few small changes to the CC1000 stack; the
>>> first was that it actually checks for CRCs, the second was the
>>> inclusion of support for 4 bit link estimation.
>>>
>>> Om, you were going to run some tests on mica2dots, right? Can you see
>>> if you encounter this problem?
>>>
>>> Phil
>>> _______________________________________________
>>> Tinyos-help mailing list
>>> [email protected]
>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>>
>> _______________________________________________
>> Tinyos-help mailing list
>> [email protected]
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
