Hello all :
   that is right , it is the problem of CC1000SendReceiveP.nc  .
   i have compare the file CC1000SendReceiveP.nc between the version of cvs
and release  . i think there is no problem in " ((uint8_t
*)rxBufPtr)[count++] = nextByte;" , because this section of programme is the
same between the two version . i find the problem exists lines 575 ,
maybe  "radioState" is always not equal to  RECEIVED_STATE , so the sentence
of return always run .
      if (radioState != RECEIVED_STATE) {
          return;
      }

i delete the return sentence , the motes can receive packets .

i don't know the real reason why radioState is not equal to  RECEIVED_STATE
, can someone give an explain ?

thank you !!

2008/6/2 John Regehr <[EMAIL PROTECTED]>:

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



-- 
zhang jiwen
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to