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