cc2520 issue

cc2520 issue

[Karol Poczesny]

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.

I had checked my radio board - I complied my system with debug in cc2520.c
and received this:

...
[ 661.896458] cc2520 spi32766.0: SFD for RX
[ 937.179079] cc2520 spi32766.0: SFD for RX

so - I received SFD interrupt for RX this function is processed and it
seems that received packet stuck somewhere on Rx path.

I'm going to track this anomaly but maybe someone had similar problem.
Maybe there are some issues related with configuration cc2520 + RPi?
Somebody tested this configuration ?

I use pretty old kernel version (3.17.0-rc1+) and old userspace tool - iz
on both sides. Configuration is this same as on openlab web.

Solution is described on my blog:
[0] http://zanaster.blogspot.com/2015/05/rpi-6lowpan-solution-with-cc2520.html

Best,
Karol

Re: cc2520 issue

[Varka Bhadram]

Hi Karol Poczesny,

On 05/12/2015 03:24 AM, Karol Poczesny wrote:

> 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 used BeagleBoneBlack with cc2520. It worked for me. Able to communicate
with TinyOS nodes.

> 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.
>
> I had checked my radio board - I complied my system with debug in cc2520.c
> and received this:
>
> ...
> [ 661.896458] cc2520 spi32766.0: SFD for RX
> [ 937.179079] cc2520 spi32766.0: SFD for RX

It will just a debug message that will indicate a packet has received. After a packet
has received cc2520 will generate SFD interrupt. 

> so - I received SFD interrupt for RX this function is processed and it
> seems that received packet stuck somewhere on Rx path.

Can you please enable the debug for mac802154 and see whether the packet is going
to the upper layers or not..?

> I'm going to track this anomaly but maybe someone had similar problem.
> Maybe there are some issues related with configuration cc2520 + RPi?
> Somebody tested this configuration ?
>
> I use pretty old kernel version (3.17.0-rc1+) and old userspace tool - iz
> on both sides. Configuration is this same as on openlab web.

Use the latest bluetooth-next [0] tree. And this iz tools are now deprecated
with the new kernel versions. Use the iwpan [1] tools (similar to iw for wireless). 

> Solution is described on my blog:
> [0] http://zanaster.blogspot.com/2015/05/rpi-6lowpan-solution-with-cc2520.html

Nice. 

> Best,
> Karol
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks,

-- 
Varka Bhadram

Re: cc2520 issue

[Varka Bhadram]

On 05/12/2015 09:12 AM, Varka Bhadram wrote:
> Hi Karol Poczesny,
>
> On 05/12/2015 03:24 AM, Karol Poczesny wrote:
>
>> 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 used BeagleBoneBlack with cc2520. It worked for me. Able to communicate
> with TinyOS nodes.
>
>> 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.
>>
>> I had checked my radio board - I complied my system with debug in cc2520.c
>> and received this:
>>
>> ...
>> [ 661.896458] cc2520 spi32766.0: SFD for RX
>> [ 937.179079] cc2520 spi32766.0: SFD for RX
> It will just a debug message that will indicate a packet has received. After a packet
> has received cc2520 will generate SFD interrupt. 
>
>> so - I received SFD interrupt for RX this function is processed and it
>> seems that received packet stuck somewhere on Rx path.
> Can you please enable the debug for mac802154 and see whether the packet is going
> to the upper layers or not..?
>
>> I'm going to track this anomaly but maybe someone had similar problem.
>> Maybe there are some issues related with configuration cc2520 + RPi?
>> Somebody tested this configuration ?
>>
>> I use pretty old kernel version (3.17.0-rc1+) and old userspace tool - iz
>> on both sides. Configuration is this same as on openlab web.
> Use the latest bluetooth-next [0] tree. And this iz tools are now deprecated
> with the new kernel versions. Use the iwpan [1] tools (similar to iw for wireless). 

iwpan/wpan-tools

[0]: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
[1]: https://github.com/linux-wpan/wpan-tools

>> Solution is described on my blog:
>> [0] http://zanaster.blogspot.com/2015/05/rpi-6lowpan-solution-with-cc2520.html
> Nice. 
>
>> Best,
>> Karol
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Thanks,
>


-- 
Varka Bhadram

Re: cc2520 issue

[Johann Fischer]

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.

 From our adapters about 40% do not work properly. This behavior depends
on temperature and the channel (frequency).

I have also observed the SPI and GPIO communication. 
If I remember correctly, it was the transceiver, which had simple not
received the packages. I will examine SPI and GPIO communication this
week (if I have time :-)).

> I had checked my radio board - I complied my system with debug in
> cc2520.c and received this:
> 
> ...
> [ 661.896458] cc2520 spi32766.0: SFD for RX
> [ 937.179079] cc2520 spi32766.0: SFD for RX
> 
> so - I received SFD interrupt for RX this function is processed and it
> seems that received packet stuck somewhere on Rx path.
> 
> I'm going to track this anomaly but maybe someone had similar problem.
> Maybe there are some issues related with configuration cc2520 + RPi?
> Somebody tested this configuration ?
> 
> I use pretty old kernel version (3.17.0-rc1+) and old userspace tool
> - iz on both sides. Configuration is this same as on openlab web.
> 
> Solution is described on my blog:
> [0]
> http://zanaster.blogspot.com/2015/05/rpi-6lowpan-solution-with-cc2520.html
> 
> Best,
> Karol


-- 
Johann Fischer

Re: cc2520 issue

[Alexander Aring]

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

Re: cc2520 issue

[Karol Poczesny]

Hello all.

Finally I have found the bug.
It was my hardware. Pin with fifo signal was unconnected. Sorry for the mess.
After quick fix with my soldering machine it runs.
Now I'm able to ping RPI with at86rf230 even without Alex's fix.

Yes Johann. I use 2450BM15B0002 Balun. But now, after few tests it works fine.
You can check the sequence of events (in debug mode via dmesg ) for
those problematic modules.
Make sure that SFD and FIFOP interrupts are received.

By the way. Maybe this is question for Varka.
Why workqueue mechanism used to invoke cc2520_fifop_irqwork [0]?
As far as I understand we can invoke this function straight from
cc2520_fifop_isr.
I just wander, what are the advantages of this solution ?

Karol

[0] http://lxr.free-electrons.com/source/drivers/net/ieee802154/cc2520.c#L693

Re: cc2520 issue

[Alexander Aring]

On Fri, May 29, 2015 at 09:18:35PM +0200, Karol Poczesny wrote:
> Hello all.
> 
> Finally I have found the bug.
> It was my hardware. Pin with fifo signal was unconnected. Sorry for the mess.
> After quick fix with my soldering machine it runs.
> Now I'm able to ping RPI with at86rf230 even without Alex's fix.
> 

my fix was just a shoot into the dark.

> Yes Johann. I use 2450BM15B0002 Balun. But now, after few tests it works fine.
> You can check the sequence of events (in debug mode via dmesg ) for
> those problematic modules.
> Make sure that SFD and FIFOP interrupts are received.
> 
> By the way. Maybe this is question for Varka.
> Why workqueue mechanism used to invoke cc2520_fifop_irqwork [0]?
> As far as I understand we can invoke this function straight from
> cc2520_fifop_isr.

At the moment you can't easily move it. Because cc2520_fifop_irqwork
will call cc2520_cmd_strobe which ends in a spi_sync call.

If you move it you would get a "BUG: scheduling while atomic..." notice.
This is because spi_sync, calls somewhere "wait_for_completion" which
waits until the spi messages is transmited and in this time spi_sync
will block. You can't do this in an interrupt context.

Alternative would be to use spi_async call, which do not wait and have
some complete handler to do the next operation when spi is finished. At
the moment with spi_async you could remove all the workqueues and also
use xmit_async callback instead spi_sync.

> I just wander, what are the advantages of this solution ?
> 

There are no advantages, the advantages would be to use spi_sync and
this is for some developers easilier to use. At the moment dealing with
workqueues will slow down the handling and you lost the context of
the called function like xmit_sync and xmit_async. In xmit_async context
you are inside the "ndo_do_xmit" callback of netdev_ops, in xmit_sync
you setup some workqueue and lost the context of "ndo_do_xmit". Simple
look here [0]. Then we queue it into a workqueue -> you will lost the
context of "ndo_do_xmit", I already tried to fix the context of this
callback while hold the rtnl lock while transmit, see [1]. But I don't
think that this will fix all the issues.

I would be very happy if we can remove the xmit_sync callback.

- Alex

[0] http://lxr.free-electrons.com/source/net/mac802154/tx.c#L99
[1] http://lxr.free-electrons.com/source/net/mac802154/tx.c#L53