Hi Sha - You're right, we are missing a check for RXFIFO overflow. Right now the maximum default CC2420 packet size in TinyOS is 41 bytes (including CRC). The RXFIFO is 128 bytes, which means you'd be able to fit 3 full packets in the RXFIFO before an overflow occurs. Although I think it may be unlikely that you'd spontaneously receive 3+ full packets in the RXFIFO due to CSMA backoffs and transmit delays, it can still happen.
But imagine this scenario: you receive 3 maxed-out packets that are valid, and get a fourth packet that causes an RXFIFO overflow, and is therefore corrupted. Do you flush the RXFIFO at that point and lose the 3 valid packets that are already in there? Or do you wait until you're reading out the fourth packet that is corrupted before flushing it? In the current scenario, you read out the amount of data as specified by the fourth packet and see that the CRC doesn't check out. Upon reading the next packet, the length is found to be invalid and the RXFIFO is flushed. Putting in an explicit check for RXFIFO overflow may be more desirable, but the question is, when is the best time to flush the RXFIFO? Right when the error occurs? Or after you get any remaining valid packets out? -David -----Original Message----- From: Liusand [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2008 10:33 PM To: David Moss; tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2? Thanks, David. I have some questions concerning RXFIFO overflow. In CC2420ReceiveP.nc, RXFIFO is flushed only when the length byte is invalid. So where is RXFIFO overflow taken care of? Can reading bytes from RXFIFO automatically clear the overflow status? Also, in CC2420TransmitP, RXFIFO overflow status is not checked before issuing the STXONCCA or STXON strobe. So if RXFIFO has already overflowed, there will be no more space for ack frame. TinyOS 1.1.15 does do this check before sending and flush RXFIFO accordingly even though I'm not sure if it is for this purpose. Thanks, -Sha -------------------------------------------------- From: "David Moss" <[EMAIL PROTECTED]> Sent: Friday, March 14, 2008 5:26 PM To: "'Liusand'" <[EMAIL PROTECTED]>; <tinyos-help@millennium.berkeley.edu> Subject: RE: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2? > The TX FIFO is preloaded with data. The data is not being transmitted to > the CC2420 as the transmission is taking place, unlike other chips. > Because > of the preload, it is impossible for the CC2420 to produce a TXFIFO > UNDERFLOW. All the data to send is available on the chip when transmit > occurs. > > Due to the rules of the CSMA and Transmit modules, a new packet cannot be > uploaded to the TX FIFO until the previous packet in the TX FIFO was > transmitted. This should guarantee that the TX FIFO be empty when the > next > transmit occurs. If a cancel occurs, a quick SFLUSHTX empties the > contents > of the TX FIFO. > > -David > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Liusand > Sent: Friday, March 14, 2008 12:45 PM > To: tinyos-help@millennium.berkeley.edu > Subject: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2? > > Hi, > > When I was studying CC2420TransmitP.nc, I noticed that TXFIFO is never > flushed and underflow status is never checked. In CC2420RadioM.nc from > TinyOS 1.1.15, TXFIFO is flushed in startSend() every time before it is > written data to. > > It might be too conservative in TinyOS 1.1.15, but why overflow is never > taken care of in TinyOS 2.0.2? > > Another related question is, in which situations TXFIFO underflow may > happen? > > Thanks, > > Sha > > _______________________________________________ > 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
