problem with device tree overlay at86rf233

[smlng]

Hi,

I use the openlabs IEEE 802.15.4 transceiver, which actually is an Atmel at86rf233 connected via SPI. There is a device tree overlay in /boot/overlays/ and if I enable it in /boot/config.txt the kernel correctly identifies the atmel transceiver, using wpan-tools I am able to setup a 6LoWPAN device or monitor. However, all frames are somehow garbled and discarded by the network stack or kernel.

If I configure a monitoring device and use tshark or something similar on it to observer 6LoWPAN traffic between 2 other nodes. I see IEEE 802.15.4 packets but their content is garbled, i.e., src and dst addresses are incorrect and so on. However the observed 2 nodes communicated successfully, its just the monitoring node with the at82rf233 that is unable to receive correct packages. Moreover in dmesg I see lots of message like this:

[   77.614344] ieee802154: bad frame received (type = 0)
[   78.608092] ieee802154: bad frame received (type = 6)
[   79.607217] ieee802154: bad frame received (type = 0)
[   80.625539] ieee802154: bad frame received (type = 0)
[   81.617464] ieee802154: bad frame received (type = 0)
[   82.617518] ieee802154: bad frame received (type = 6)

This only happens when I use Raspbian with default Kernel and the at86rf233 overlay. A self compiled kernel using this guide does work. The major difference is, that it uses bcm2835 configs and not bcm2708 configs for Pi b or b+ and it recompiles device trees, so no overlays involved here.

Has somebody else problems with the at86rf2xy transceivers. I think something is wrong with device tree definition for bcm2708 and the params for SPI.

[pelwell]

Can you save out the device trees from both configurations and then upload them somewhere, e.g. a gist?

Install the dtc package if you don't have it, then use dtc -I fs /proc/device-tree > name.dts.

[smlng]

Hi I recorded the dts as suggested for both configs see here the first one (bcm2835-rpi-b-plus) is working, it uses a self compiled kernel with modified dts file, no overlay here. The other one (bcm2708-rpi-b-plus) uses latest Raspbian image and kernel with dtoverlay for at86rf233, is not working -> content of IEEE 80215.4. frames is garbled.

[smlng]

oh sorry files are in reverse order, so check the names not first second ...

[pelwell]

Hmm. There are a lot of differences between the two, but the at86rf233@0 node is the same in both. The clocks, although named differently, also seem to be the same. Somebody on the original issue (#1151) might be able to help.

[smlng]

Ah, thanks for the pointer, I'll try some different frequencies with the overlay. However, even if this might work, it's weird that there is no problem with high frequencies and a self compiled kernel + device tree using no overlay ... But first I've to check and verify that, I'll report soon

[smlng]

Hi again,

so I tested some different frequencies for SPI. I first dropped from 6MHz to 2MHz and everything worked liked charm, which was kind of relief. Afterwards I raised it to 4MHz and it didn't work as good: some frames were accepted (so a few pings went through) but for most packets the payload was mixed up again. However, with 6MHz the whole frame was a mess including src and dst address, with 4 MHz the IEEE 802.15.4. and 6LoWPAN part/headers seemed okay only the payload (ICMPv6 for pings) had incorrect checksum and was garbled.

Finally I settled for 3MHz, which allowed for stable pings over a long period, no packet loss or messed up frames any more. So I would suggest to lower SPI frequency to 3MHz in the at86rf233-overlay, at least for now. I only tested with a Pi 1 B+, but I also have some Pi 2 Bs floating around here - maybe they support higher SPI freqs. Btw. is it possible to write the overlay in such a way to support Pi 1 and 2 but with different freqs?

Cheers, and thanks for the help. IMHO this issue is resolved for the time being ...

[smlng]

Oh one thing, just to let you know: I also tested another transceiver namely a microship mrf24j40ma, and copied an overlay from this blog here. This transceiver works stable with SPI frequency of 5MHz, also running latest Raspbian release with kernel version 4.1.17+ and dt overlay. So maybe this is not totally SPI related but also driver dependent - but that's just guessing around, I have not enough experience with kernel device trees or the drivers of the transceivers.

[pelwell]

You already have the ability to set the speed on a per-Pi basis using the "speed" parameter:

dtoverlay=at86rf233,speed=3000000

If you had a card that was shared between Pis then you could put multiple dtoverlay directives into [pi1] and [pi2] sections, but the existing overlay mechanism doesn't have a way to include machine-specific sections - that's an interesting idea.

SInce you are up for building your own kernel, it would be interesting to see if reverting 853eff4 helps the bcm2708 build at all.

[pelwell]

OK to close?

[smlng]

Fine with me, thanks again!