Hello. On Wed, 2011-06-15 at 15:13, bala krishna sanjeeva wrote: > > I have used openembedded for flashing images on to the > imote2. Openembedded uses the linux zigbee kernel. Imote2 > is a sensor board with cc2420 radio chip. I have written a > transmit and receive program using header files > from the user space applications provided in the linux-zigbee project. I > am able to transmit and receive data.
Is that the regular OpenEmbedded image with the 2.6.33+ kernel or did you compile the kernel yourself? I'm working on the same hardware, again, here but starting with the 2.6.38 patches posted on this list. > The > problem is with the receiving. It works fine for a few duration but due > to some reason,there is an overflow and the data is no more received. Thats due to sfd and fifop having the same low-level intereupt handler and sharing the same irq_disabled marker. That leads the slowpath warning in enable_irq you are seeing below. I have worked out a fix for that among others but haven't send it yet as I'm stuck with some other problems in the driver to have it fully tested and verified. > This happens when the receiver receives data from another source and not > from the node (imote) that I am using. Actually it is a race on the irq_disabled variable in the local struct. > I guess its due to > interference from other wireless devices. Have anyone of you faced this > problem. Can anyone offer any suggestions for this problem? As I said I should have a fix for this, just split up the irq handler in two handlers. Each for fifop and sfd. Also using two different variable for the irq_enabled state. That fixed the issue for me. Sadly this does not make the driver reliable either. :( As SFD gets raised for TX as well as for RX after the start frame delimiter was found we need to detect in which case we are. Ideally that should be done by doing a STXONCCA strobe to wait for a clear channel before sending, wait for SFD getting high and check the TX_ACTIVE bit in the status byte if we are in TX mode. Once TX_ACTIVE was is off again we are in receive mode again. Now the real problem starts. I just have seen the TX_ACTIVE bit set in very rare cases and instrumenting the reg_read function shows that the SPI read can take a _long_ time. I measured up to 25 _milli seconds_ and minimum was 500 micro seconds. That explains why I'm already in state 6 (RX_SEARCH_FOR_SFD) when requesting the status byte directly after the strobe. Our best guess here so far is that the spi functions are sleeping and the scheduler does other work and we are missing the transmit window completely. A crosscheck with the contike driver on another board but same rf chip shows that the logic is correct and the drivers atcually sees the TX_ACTIVE bit as well being in different states of the FSMSTATE register. That platform is using gpio bitbanking thought and its contiki not linux. So far I tried various option to enable/disable the DMA of the pxa2xx spi driver as well as changing the thresholds and timout without luck. :( If anybody else here has some hints on this I'm happy to test suggestions as I'm running out of ideas. The last one I still have is to avoid the pxa2xx spi driver and use some simple spi bitbanging. :/ > Also I am trying to understand the lower layers and its working. I will try to prepare my patches tomorrow and send them out to get you started. Maybe you have other ideas on how we can get this driver working reliable. Three patches should be save to apply: 1) Split the irq_handler into two separate ones to avoid race on irq_enabled var. That fixes the issue you are reporting. 2) Fix AUTO ACK for long addresses and tell the stack that we do hardware acking of frames. 3) Checking for the FCS valid bit to skip frames with a wrong CRC. The rest is mostly still in testing and debugging to have a reliable handling for the RF state machine. regards Stefan Schmidt ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
