Thanks again for your patient reply. Please CIL. On Thu, Oct 11, 2012 at 8:57 PM, Eric Decker <[email protected]> wrote:
> > > On Wed, Oct 10, 2012 at 10:53 PM, Xiaohui Liu <[email protected]> wrote: > >> Hi Eric, >> >> Thanks for your prompt reply. Please see my comments inline. >> >> On Wed, Oct 10, 2012 at 9:12 PM, Eric Decker <[email protected]> wrote: >> >>> Welcome to the real world. >>> >>> A production/robust stack should handle these issues. I haven't spent >>> enough time with the current cc2420 stack to know how far it was taken. >>> >>> I will one of these days visit this issue because I need a production >>> quality radio stack for the CC2520 radio. So will dig into it at that >>> time. >>> >>> In the meantime ... >>> >>> On Wed, Oct 10, 2012 at 4:05 PM, Xiaohui Liu <[email protected]> wrote: >>> >>>> Hello everyone, >>>> >>>> Normally, if a packet is corrupted, the CRC is supposed to detect and >>>> discard it, at least with very high probability. However, if the corruption >>>> happens on the length field, are these issues handled by the radio stack? >>>> >>> >>> This issue is partially handled by the existence of a special sequence >>> of symbols called the SFD (Start Frame Delimiter). >>> >>> Also if the length is corrupted the CRC will cause the packet to >>> abort. There is a defined maximum length for a packet which will also >>> cause the packet to abort prior to doing a CRC calculation. So if the >>> packet is too long but below the max length, the CRC will be computed and >>> should cause the packet to abort. Seeing the start of another frame >>> should also cause the packet to abort. >>> >> > > >> By aborting a packet, you mean the CC2420 h/w terminates its reception >> and the packet will not be placed at RXFIFO, or the packet is placed into >> RXFIFO but flushed by the CC2420 driver later? >> > > yes. Depends on the system design and how it works and what is > enabled. The CC2420 is very flexible. I don't know what the current > design has programmed it to do. I do know the mostly the simple default > implementation was done based on what Chipcon originally provided as the > reference implementation. Typically reference implementations don't > handle the corner/exception cases. The problem you are describing is > certainly one of the exception cases. > > >> 1) the corrupted length is larger than the actual bytes buffered in >>>> RXFIFO, and RXFIFO.beginRead() or RXFIFO.continueRead() is called to >>>> read rxFrameLength bytes from it. What could happen in this case? >>>> Underflow? >>> >>> >>> There should be special signalling between the CC2420 h/w and the CC2420 >>> driver. This signalling should tell the driver that we have an abnormal >>> packet. Either we have received another SFD prior to the current packet >>> finishing or that we have an underflow (we the h/w stopped seeing symbols >>> prior to its idea of when the packet should be finished). >>> >>> Both of those conditions must be handled in a robust driver. I don't >>> know how far the implementers of the current CC2420 driver took things. In >>> the little bit of looking I've done, I haven't seen evidence that these >>> conditions are handled. The CC2420 driver was based (from the looks of >>> things) on some sample TI/Chipcon code that talks to the chip using some >>> default setup. And special handling of exception processing has to be >>> programmed into the chip special. It is actually quite capable chip. >>> But it has to be because it is an off-load processor. (I used to design >>> this kind of stuff (inter cpu communications, multi-processors, etc. when >>> things were much much larger). >>> >>> >>>> >>>> 2) the CRC is read at the wrong offset ((buf[rxFrameLength] >> 7)). And >>>> it can happen to be 1, causing the corrupted packet to be signaled to upper >>>> layers as a correct packet even though it is not. >>>> >>> >>> I don't understand what you are saying is the behaviour. If the CRC is >>> at the wrong offset, how can it be correct? I think one should get an >>> indication that the packet is bad. >>> >>> > >> AFAIK, there is no special signalling you mentioned above between the >> CC2420 h/w and the current CC2420 driver. This can happen when the h/w >> passes a packet with corrupted length filed to the driver. For instance, if >> the correct rxFameLength is 21, but it is corrupted and now becomes 20. >> > > Have you physically seen this happen? > > Yes. Only packets with fixed length are sent, but packets with different length are received by the default driver, passing CRC check. Out of all these packets, about 3% are actually corrupted as my measurement shows, a much higher false positive ratio than what CRC is supposed to give. This is why I started investigating this issue in the first place. Is there anyway to discard such packets with corrupted length field, maybe at the h/w level? CRC checking does not work well since the offset of CRC bit is wrong. BTW, the CRC checking does not include the length filed according to the datasheet. > If the h/w is really doing this something is broken in the h/w (cc2420 > module). The packet should have been aborted because of a bad CRC and the > driver shouldn't have ever seen it. If that is the case, that is what is > wrong and should be debugged because it is incorrect system behaviour. > > >> So instead of CRC failure as (buf[21] >> 7) indicates, CRC passes since >> (buf[20] >> 7) is mistaken for CRC, which happens to be 1. Of course, if >> there is special signalling, this should not happen. >> > >> Note, we should also be instrumenting the behaviour of the device and >>> there isn't any that I've found. It should also be instrumentation in the >>> cc2420 that one can get. Stuff like how many bad packets are we seeing and >>> or what reasons. Otherwise how does one debug what is going on. But it >>> is difficult doing this in a severly resource constrained system. >>> >>> >>>> 3) this has a cascade effect if there are additional packets buffered >>>> in RXFIFO after this corrupted one. Their lengths can also be mistaken >>>> because the previous packet uses a wrong boundary, identified by the wrong >>>> length field. >>>> >>> >>> Shouldn't happen. Because a new SFD should cause the current packet to >>> be closed out. It should be flagged as bogus. I don't know the details >>> of how this works given the FIFO design of the CC2420. >>> >> > >> Do you know where I may find more information regarding the inner >> working of CC2420 FIFOs, namely, TXFIFO and RXFIFO? I haven't found much on >> the datasheet. I want to understand many details such as the layout of >> multiple frames in the RXFIFO. >> > > the only information I have so far is the cc2420 data sheet. As I've > said I haven't delved into the radios yet and when I do it will be on the > CC2520 and 2591. > > The data sheet I have for the cc2420 (CC2420 > Datasheet<http://www.ti.com/litv/pdf/swrs041b>). > > > I've poked around a bit and didn't see anything else either for the cc2420 > or the cc2520 (the 2520 is very close to the same interface as the 2420). > > I did see some example s/w that you might be able to look at. Not sure > what kind of format it is in (.exe weird). Take a look at the cc2520 web > package from TI. Then look at what s/w they provide. The SimpliciTI > code might give some clues as to how to play with the FIFO. I haven't > looked. > > Short of finding something else (I've looked, didn't find anything) you > can start interacting with the TI Tech Reps to see if you can get any other > technical information about how it all works. There are little drips and > drabs in the various tech notes. But it is pretty opaque. Which is > obnoxious. > > > > >> If the driver/h/w got it wrong then it is indeed a problem. If the >>> interface between the driver and the cc2420 isn't correct, then one >>> probably has to flush the queue and start over. Because you really don't >>> have any other choice. For the reasons you've stated. >>> >>> >>>> >>>> This seems a severe issue but I haven't found any measure to cope with >>>> it in the stack. Can anyone please give me a hint? Thanks sincerely in >>>> advance. >>>> >>> >>> I concur and why I beleive it hasn't been handled. It is a corner case >>> which production code and deployment want to deal with but typically don't >>> get dealt with in academic environments. >>> >>> I don't beleive it has been dealt with but am willing to be wrong. The >>> above is my current cursory (I've haven't picked the code apart to analyzie >>> it for correct operation as well as a corner case analysis) observations >>> about the state of the CC2420 driver. >>> >>> I will be doing a full analysis of the cc2420 stack when I implement the >>> cc2520 driver. It will start being a clone but will have to change >>> because we are using the 2591 range extender which will change what pins >>> are used for what function. I will probably also have to change the >>> driver/radio interface in other ways to handle corner cases that haven't >>> been changed. >>> >>> I probably won't back-port the changes to the cc2420. But we'll see. >>> >>> >>> >>>> >>>> -- TelosB >>>> -Xiaohui Liu >>>> >>>> > Eric > > > > -- -Xiaohui Liu
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
