[Tinyos Core WG] Re: CC2420 stack

[David Moss]

I made changes to CC2420ReceiveP (attached) to explicitly 
check if the packet length is 0 before trying to read it 
in.  If the length == 0, it doesn't even bother with the 
SPI bus; instead, it will release the bus and 
waitForNextPacket().  The micaz receiver I have here has 
been running for a long time with no random reboots.

This means the actual 0 length read issue still exists in 
the actual atm128 SPI bus driver, so it should be updated 
separately as well.

I have only committed the CC2420ReceiveP fix to 
tinyos-2.x-contrib/rincon/tos/chips/cc2420_lpl, and have 
not committed it to the baseline because  it has not 
tested it with the default baseline radio stacks.

It's a giant relief to see this issue go away.  Thanks for 
everyone's time and input in tracking this down.

-David



On Thu, 22 Feb 2007 06:49:50 -0800
  Jonathan Hui <jhui at archrock.com> wrote:
> 
> The RXFIFO may contain *multiple* packets, regardless of 
>whether they are valid or corrupt. Remember that a length 
>of zero meant the packet was actually 1 byte long (the 
>length byte itself). So you still read out that byte, 
>then move on to what hopefully is a good packet after 
>that.
> 
> In general, you don't flush the RXFIFO whenever you 
>think you have a corrupt packet. You could be flushing 
>good packets as well.
> 
> --
> Jonathan Hui
> jhui at archrock.com
> 
> 
> Jung Il Choi wrote:
>> Wouldn't it be right to just flush the RXFIFO if the 
>>length is 0? I think there'll be no way we can parse out 
>>packets from RXFIFO if the length is damaged. 
>> 
>> Jung Il
>> 
>> ----- Original Message ----- 
>> From: "Jonathan Hui" <jhui at archrock.com>
>> To: "David Moss" <dmm at rincon.com>
>> Cc: "Philip Levis" <pal at cs.stanford.edu>; "Jung Il Choi" 
>><jungilchoi at stanford.edu>; "John Regehr" 
>><regehr at cs.utah.edu>; <ram at rincon.com>
>> Sent: Wednesday, February 21, 2007 7:45 PM
>> Subject: Re: CC2420 stack
>> 
>> 
>>> From looking at the code, it's pretty clear that the 
>>>atm128 SPI stack 
>>> does not handle a SpiPacket.send() with a length of 0 
>>>properly. Just 
>>> check if the length is zero, post a task and signal the 
>>> SpiPacket.sendDone() event. In fact, it will try to 
>>>transfer 65535 bytes 
>>> since we're dealing with 16-bit values.
>>>
>>> --
>>> Jonathan Hui
>>> jhui at archrock.com
>>>
>>>
>>> David Moss wrote:
>>>> I think you're definitely on the right track here.
>>>>
>>>> I haven't tried implementing your suggestion, but have a 
>>>>few more 
>>>> observations to add.  After some amount of testing on my 
>>>>end, the traces 
>>>> I'm using keep returning information to me up until 
>>>>CC2420SpiImplP 
>>>> actually executes "call SpiPacket.send( NULL, data, len 
>>>>);"  - 
>>>> immediately after that point, and deeper into the SPI 
>>>>realm, my traces 
>>>> stop responding and the mote reboots.
>>>>
>>>> I tried removing the call to "continueRead()" completely 
>>>>from 
>>>> CC2420ReceiveP and in place of that, flushed out the RX 
>>>>FIFO using:
>>>>
>>>>     call CSN.set();
>>>>     call CSN.clr();
>>>>     call SFLUSHRX.strobe();
>>>>     call SFLUSHRX.strobe();
>>>>     call CSN.set();
>>>>     call SpiResource.release();
>>>>
>>>> My mote certainly took much longer before another reboot 
>>>>occurred.  But 
>>>> when that reboot did occur, it was consistently right 
>>>>after this call in 
>>>> CC2420ReceiveP:
>>>>
>>>>     call RXFIFO.beginRead( (uint8_t*)(call 
>>>>CC2420Packet.getHeader( 
>>>> m_p_rx_buf )), 1 );
>>>>
>>>> As we see from CC2420SpiImplP, the beginRead call is 
>>>>just an extension 
>>>> of continueRead().
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, 21 Feb 2007 18:37:40 -0800
>>>>  Philip Levis <pal at cs.stanford.edu> wrote:
>>>>> On Wed, 2007-02-21 at 17:34, Jung Il Choi wrote:
>>>>>> Maybe we should look at it backwards. I put NULL for 
>>>>>>both cases on 
>>>>>> the line David mentioned and I couldn't see reboots. So 
>>>>>>that means 
>>>>>> the problem was the buf+1 side, not the NULL side.
>>>>>> So I added a condition to flush the RXFIFO when length 
>>>>>>(which is 
>>>>>> buf[0]) is zero, and now I don't see reboots for more 
>>>>>>than 15 
>>>>>> minutes. I am not sure if this is just for my case or 
>>>>>>not, but I 
>>>>>> think it's worth trying.
>>>>> The code I sent won't work exactly (you'll never read 
>>>>>into index 0 of
>>>>> the array). I'm sure you can figure it out, Jung.
>>>>>
>>>>> Phil
>>>>>
>>> >

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CC2420ReceiveP.nc
Type: application/octet-stream
Size: 10477 bytes
Desc: not available
Url : http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20070226/1e017b12/CC2420ReceiveP.obj