On 02/05/2013 07:11 PM, Sascha Herrmann wrote: >> This is exactly what I meant. There's no reason to store it in the >> at86rf230_local struct though, since it's only ever used in >> at86rf230_probe(). > > Yes, you are right. I will change that and add a comment to platform_data > field. > > > While the basic function works with this patch for my rpi, I got an > additional problem. When sniffing a ZigBee network the driver stops > working after receiving a random (but small) number of non broadcast > packets. > > I was able to trace this down to the interrupt handling of the driver. > In at86rf230_isr() the interrupt is disabled at the first line of the > function and gets enabled again in at86rf230_irqwork() after processing > the interrupt (which includes reading the whole received frame from the > radio chip). Because of this the driver is blind to new interrupts while > processing an received frame, and because the rf230 resets its interrupt > line only after we read its interrupt status register the driver stops > working if a new interrupt is generated in this time frame. > > Attaching a scope to the interrupt line, watching the last interrupts > before the driver stops working, one can see up to three interrupts for > each packet. The first one is the RX_START interrupt, 500us after this > the AMI (Adress Match Indication) interrupt is generated and only about > 25us after this interrupt is handled (interrupt line goes down) the > TRX_END interrupt follows. If the driver miss this interrupt the rf230 > doesn't reset its interrupt line and the driver can't detect any new > interrupt. (http://defekt.int.nvbi.de/sascha/rf230_stale_irq.JPG)
Can you set the at86rf230 to only interrupt with TRX_END? Isn't that the one you really want? > > For my setup I was able to resolve this problem by completely removing > the disabling / enabling of the interrupt in the driver. As far as I can > see it, disabling the interrupt doesn't make any sense for edge > triggered interrupts. Are there any platforms, that will retrigger the > interrupt, while the interrupt line is high, so that it is necessary to > disable the interrupt while handling it? Or was the assumption, that the > rf230 would automatically reset its interrupt line? I guess the point is to not try to access the device while the reading of the data is being done. I'm not sure this is necessary though, for two reasons. 1: SPI messages (spi_sync()) execute atomically with respect to each other, and 2: all the SPI is done from a workqueue anyway, which is serialized. Dmitry, Alexander, do you have any insight into this? Alan. > At the moment I am not sure what would be the right solution here. I > think removing the calls to disable / enable the irq would do the trick, > but I don't know if it breaks some other setups :( ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
