Re: cc2520 issue

[Alexander Aring <alex.aring@gmail.com>]

On Wed, May 13, 2015 at 04:46:33PM +0200, Johann Fischer wrote:
> Hi Karol,
> 
> > Hello all,
> > 
> > I have tested simple ping communication between two devices:
> > 1.) Raspberry Pi with at86rf233 transceiver - (openlab module)
> > and
> > 2.) Raspberry Pi with CC2520 transceiver - my own radio board.
> > 
> > I am able to run the interface and start transmit frames for both
> > nodes, but only node with at86rf233 respond.
> > 
> > Node with CC2520 can send e.g ping message but cannot answer for ping
> > from at86rf233 node and ignore any other requests.
> > 
> 
> As I see, you used a reference Design with 2450BM15B0002 Balun?
> 
> I use also TI's reference design with the Balun and have the same
> problems. Original TI CC2520EM 2.1 Board functions fine.
> I use Kernel 3.19.0.
> 
> The problem appears only after immediately switching from tx to 
> rx mode. (e.g. ping6). Just send or receive is fine.
> 

this smells for me like a missing interframe spacing time. The 802.15.4
standard describes a minimum "waiting" time after reach transmit  ->
interframe spacing time.

I had the same issue in at86rf230 driver while 6LoWPAN fragmentation and
not in CSMA-CA/ARET mode.

The question is always "who do the interframe spacing time" if it's
not the transceiver which do simple a delayed tx completion irq (which
included the interframe spacing time), then this need to be handled by
the upper stack/driver layer.

If the datasheet nothing said about the interframe spacing time, then
it's bad. In my case I asked the atmel support and they told me that the
stack need to handle the interfame spacing time.

Anyway, the mac802154 contains a handling for this, but the driver
doesn't support xmit_async right now and an ugly workaround would be:

diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
index 84b28a0..0d18ca4 100644
--- a/drivers/net/ieee802154/cc2520.c
+++ b/drivers/net/ieee802154/cc2520.c
@@ -503,6 +503,11 @@ cc2520_tx(struct ieee802154_hw *hw, struct sk_buff *skb)
        cc2520_cmd_strobe(priv, CC2520_CMD_SFLUSHTX);
        cc2520_cmd_strobe(priv, CC2520_CMD_SRXON);
 
+       if (skb->len > 16)
+               usleep_range(640, 700);
+       else
+               usleep_range(192, 250);
+
        return rc;
 err:
        spin_lock_irqsave(&priv->lock, flags);

Maybe give it a try. If it's working "better" afterwards, then it looks like
the transceiver don't do an interframe spacing time.

Look how at86rf230 deals now with the inteframe spacing time (doesn't
required to do a sleep/delay). See [0], but this requires xmit_async
callback.

To set the symbol_duration in driver is currently a workaround, they are
well defined by 802.15.4 and should be set in upper calls when channel/page
is set. Anyway, this doesn't matter for this kind of transceiver which
always use a symbol_duration of 16 us.

- Alex

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ieee802154/at86rf230.c?id=24ccb9f4f7a3a5a867bbc880019cdb4b41176b63