On 11/05/2013 10:09 AM, K F wrote: > 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.
Hi Kostas, I did similar, but we haven't gotten into production yet: http://tineras.com/2013/02/15/prototype-mrf24j40ma-beaglebone-cape/ > 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? Until 3.12 it is. At 3.12 they fixed the fortran numbering to make it match the TRM. > 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>; > Some of the GPIO lines on the beaglebone crash when you try to use them as interrupts. I don't know why. Contact your TI FAE :) > 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. :) Your SPI communication isn't working and/or you're not getting interrupts. Alan. ------------------------------------------------------------------------------ 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
