Hi, On Wed, Feb 06, 2013 at 01:11:11AM +0100, 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 am working with the at86rf230 driver too at the moment. And I have exactly the same problem. I turn debug message on, you can do that too if you set #define DEBUG at beginning of file which use 'pr_debug'. In a big transmission (for example a ssh connection) with lot of fragmentation I got problems, pings are just fine. When I try to establish a ssh connection I got a lot of fragmentation packets until I get: 'timer expired for frame with tag 13' I don't know if that is the problem your have. But I have several another problems... izcoordinator doesn't set my channel to 11. It's on default value '-1' which is '255'. I get no error message or similar. That's the primary problem which I am working on at the moment. > 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) > > 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 That's not helped for me. Regards Alex > 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? > > 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 :( > > Thanks, > Sascha > > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
