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