Hello all,
Some research colleagues and I have designed a BBone cape which, among
other stuff, supports 802.15.4 communication (via the mrf24j40 chip).
We are in the process of testing this specific functionality, but we get
some errors I was hoping you could help me with.
The steps we followed and the results can be found below:
- Enabling spidev and testing direct communication with the chip registers:
this seems to work fine.
- Loading “mrf24j40” kernel module. In this case, the startup script
provided by you is able to find the transceiver and set the interface
correctly. Besides, the module was tested in two ways:
- Upgrading distro by using opkg (as we saw there was a mrf24j40 driver
available that required an upgrade)
- Recompiling a new 3.8 kernel (using the repository often suggested here
for its MRF support) went fine.
- We used “cape-bone-mrf24j40-00A0.dts” as reference for our own dts file.
However we had to do some changes, as the pin assignment in our case is a
bit different due to layout routing causes.
In more detail:
INT: we use GPIO2_1 while the original pin was GPIO1_29
RESET: we use GPIO1_14
WAKE: we use GPIO0_27
Thus, apart from modifying the pin mapping, we changed the original
interrupt pin assignment from:
interrupt-parent = <&gpio2>; // seems that in the dts file the gpio block
is always +1, is it right?
interrupts = <29>;
To:
interrupt-parent = <&gpio3>;
interrupts = <1>;
However, after doing this, the kernel crashed when loading the cape. So we
did a dirty fix by connecting together INT pin and WAKE pin (according to
the datasheet WAKE pin is by default not taken into account… is this right
or may affect the chip behavior?) and modifying the dts file to use the
WAKE pin as the interrupt source as follows:
interrupt-parent = <&gpio1>;
interrupts = <27>;
With this changes, the cape was loaded correctly, and the module
automatically recognized. However, when trying to do further testing by
using izcoordinator and izchat between 2 boards, we always obtain the
following kernel debug message: “mrf24j40 spi1.0: Error Sending. Retry
count exceeded”.
Having a look at the kernel module code, this message is generated by the
“mrf24j40_tx” function after reading the TXNSTAT register to check the
transmission status. However, it seems that the interrupt is indeed raised,
so this error may be caused by another reason.
Any ideas/feedback regarding our test procedure would be appreciated. :)
Kind regards,
Kostas F.
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
