Re: [beagleboard] SPI input is always 0 with BeagleBoneBlack Anstrom images

[Jack Mitchell]

The SCLK mode is wrong, it should be an input.

--

Jack Mitchell (ja...@embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk

--



On 06/05/13 14:40, Alan Backlund wrote:
> I have been trying to get SPI1 working on my new BB-Black, the output
> works but the input always reads 0.
>
> The first thing I discovered is that SPI1 is used by the HDMI
> interface. I created a modified am335x-bone-common.dtsi with the hdmi
> sections removed. Putting the new am335x-boneblack.dtb into /boot and
> rebooting got rid of the SPI1 signals. I then loaded a new device tree
> that enables spidev (See bone-test.dts below). /dev/spidev1.0 appeared.
>
> I tried running a test program that transferred a few bytes with
> spi1_d0 connected to spi_d1. The output of this program on my old BB
> White loaded with
> Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.11.22.img,
> using /dev/spidev2.0 was:
> cmd: 0x02 0x12 0x34 0x56
> rsp: 0x02 0x12 0x34 0x56
>
> with
> Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.04.13.img on
> my BB Black it's always:
> cmd: 0x02 0x12 0x34 0x56
> rsp: 0x00 0x00 0x00 0x00
>
> Looking at the signals with a logic analyser showed that the output
> (SPI1_D0) is correct.
>
> I then moved the micro SD card from my BB Black to my BB White and
> discovered that it does the same thing, so the problem is not the
> Black but in the 2012.11.22 image (the only one that supports the
> Black). The problem seems to me be in the spidev driver or in the
> underlying hardware driver.
>
> Any ideas?
>
>
> _bone-test.dts_
> /*
> * Copyright (C) 2013 Alan Backlund
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> */
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
> part-number = "BB-BONE-TEST-01";
> version = "00A0";
>
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
> bone_replicape_spi1_pins: pinmux_replicape_spi1_pins {
> pinctrl-single,pins = <
> 0x190 0x13 /* P9_31 = mcasp0_aclkx.spi1_sclk
> , OUTPUT_PULLUP | MODE3 */
> 0x194 0x33 /* P9_29 = mcasp0_fsx.spi1_d0
> , INPUT_PULLUP | MODE3 */
> 0x198 0x13 /* P9_30 = mcasp0_axr0.spi1_d1
> , OUTPUT_PULLUP | MODE3 */
> 0x19c 0x13 /* P9_28 = mcasp0_ahclkr.spi1_cs0
> , OUTPUT_PULLUP | MODE3 */
> >;
> };
> };
> };
>
> fragment@1 {
> target = <&spi1>;
> __overlay__ {
> #address-cells = <1>;
> #size-cells = <0>;
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&bone_replicape_spi1_pins>;
> cs-gpios = <&gpio4 17 0>, <&gpio1 7 0>;
>
> cs0-device {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "spidev";
> reg = <0>;
> spi-max-frequency = <16000000>;
> };
> };
> };
>
> };
>
> _spi-test.c_
> /*
> * Copyright (C) 2013 Alan Backlund
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> */
> #include <stdio.h>
> #include <stdlib.h>
> #include <stdint.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <sys/ioctl.h>
> #include <linux/types.h>
> #include <linux/spi/spidev.h>
>
> int fd;
>
> int main(int argc, const char *argv[])
> {
> const char *spidev = "/dev/spidev1.0";
> if (argc == 2)
> spidev = argv[1];
> fd = open(spidev, O_RDWR);
> if (fd < 0) {
> perror("file open");
> abort();
> }
>
> uint8_t cmd[4], rsp[4];
> cmd[0] = 0x02;
> cmd[1] = 0x12;
> cmd[2] = 0x34;
> cmd[3] = 0x56;
>
> struct spi_ioc_transfer tr;
> tr.tx_buf = (unsigned long)cmd;
> tr.rx_buf = (unsigned long)rsp;
> tr.len = 4;
> tr.delay_usecs = 0;
> tr.speed_hz = 0;
> tr.bits_per_word = 0;
>
> int ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr);
> if (ret < 0) {
> perror("ioctl");
> }
>
> printf("cmd: 0x%02X 0x%02X 0x%02X 0x%02X\n", cmd[0], cmd[1],
> cmd[2], cmd[3]);
> printf("rsp: 0x%02X 0x%02X 0x%02X 0x%02X\n", rsp[0], rsp[1],
> rsp[2], rsp[3]);
>
> close(fd);
> }
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Alan Backlund]

Changing SCLK to an input works.

Thank You

[ky...@cranehome.info]

Isn't that the serial clock?  Isn't it generated by the host and thus an output?  Or is it generated by some hardware and taking it over as an output is clobbering that?

[ky...@cranehome.info]

Ok at least I'm not that stupid then. ;)

On Tuesday, May 7, 2013 10:51:59 AM UTC-5, wb666...@gmail.com wrote:

Its a quirk of the SPI hardware as far as I can tell, even on the original Beagleboard the SPI_CLK pinmux has to be set as an input.

[randy rodes]

Wally

On Tue, May 7, 2013 at 8:21 AM, <wb666...@gmail.com> wrote:
> Thanks for posting this, I just got my Beaglebone Black last night, I'm new
> to Angstrom and dts files so I've no real idea at the moment as to how to
> actually use this information.
>
> But I'm having a problem on the Pandaboard ES (various kernels) and
> Beaglebone (3.2.23-psp18 ubuntu 12.04 rfs) where actually using the spidev
> results in random (as far as I can tell) very long latencies in the spidev
> driver.
>
> I've posted test code:
>
> http://eewiki.net/download/attachments/12059008/swave_spidev.c?version=1&modificationDate=1365778735227&api=v2
>
> that shows the problem, and includes some data for test runs on the PandaES
> and original BB in the comments.
>

I use extensively the spidev on beaglebone to talk to an external peripheral.
I use ubuntu 12.10 with 3.8.x kernel.

I happened to take a scope plot of the spi transfers.
I would strongly agree there is something really bad going on with SPI.
I saw a small message of 100Bytes transfer takes around 100ms of time
to transfer.

Looks the problem is real.
I have not investigated but looks you are facing the same issue.

> Would you be so kind as to try it on your Beaglebone Black to see if the
> issue is resolved or not in the 3.8.6 Angstrom kernel?
>
> You'd have to edit the spidev name string and GPIO pin number to match the
> BBB. Basically it tries to setup a realtime 1 Khz servo loop
> that dumps data out the spidev for a waveform generator application.
> Writing the spidev breaks realtime with long latencies, whereas toggling a
> GPIO pin instead results in good performance.
>
> TIA,
> --wally.

>
>
>
> On Monday, May 6, 2013 8:40:38 AM UTC-5, Alan Backlund wrote:
>>
>> I have been trying to get SPI1 working on my new BB-Black, the output
>> works but the input always reads 0.
>>
>> The first thing I discovered is that SPI1 is used by the HDMI interface. I
>> created a modified am335x-bone-common.dtsi with the hdmi sections removed.
>> Putting the new am335x-boneblack.dtb into /boot and rebooting got rid of the
>> SPI1 signals. I then loaded a new device tree that enables spidev (See
>> bone-test.dts below). /dev/spidev1.0 appeared.
>>

[shedmeister]

I'm trying to write user-space SPI1 driver in slave mode.  I just got past the bus errors trying to access the SPI registers without first turning on the clock in the clock module.  Now I'm not able to change the pin mux settings:

#define MUX_SPI1_CS0   0x99C

#define MUX_SPI1_D0    0x994

#define MUX_SPI1_D1    0x998

#define MUX_SPI1_SCLK  0x990

#define CONTROL_MODULE_BANK_SIZE  0x2000 /* 8K */

Control_Module_Base = 0x44E10000;

   m_controlModule = (uint32_t *)mmap(NULL, CONTROL_MODULE_BANK_SIZE,

                                      (PROT_READ | PROT_WRITE),

                                      MAP_SHARED, m_io_fd,

                                      Control_Module_Base);

Read initial pin mux values:

   printf("%s(): old MUX vals:\n"

          "MUX_SPI1_CS0  = 0x%08X\n"

          "MUX_SPI1_D0   = 0x%08X\n"

          "MUX_SPI1_D1   = 0x%08X\n"

          "MUX_SPI1_SCLK = 0x%08X\n", __FUNCTION__,

          m_controlModule[MUX_SPI1_CS0/4],

          m_controlModule[MUX_SPI1_D0/4],

          m_controlModule[MUX_SPI1_D1/4],

          m_controlModule[MUX_SPI1_SCLK/4]);

output:

 0x33, 0x33, 0x23, 0x23

Write new values:

   m_controlModule[MUX_SPI1_CS0/4]  = 0x3B;

   m_controlModule[MUX_SPI1_D0/4]   = 0x3B;

   m_controlModule[MUX_SPI1_D1/4]   = 0x1B;

   m_controlModule[MUX_SPI1_SCLK/4] = 0x3B;

Read back values:

 0x33, 0x33, 0x23, 0x23

Any ideas?

On Monday, May 6, 2013 9:40:38 AM UTC-4, Alan Backlund wrote:

I have been trying to get SPI1 working on my new BB-Black, the output works but the input always reads 0.

The first thing I discovered is that SPI1 is used by the HDMI interface. I created a modified am335x-bone-common.dtsi with the hdmi sections removed. Putting the new am335x-boneblack.dtb into /boot and rebooting got rid of the SPI1 signals. I then loaded a new device tree that enables spidev (See bone-test.dts below). /dev/spidev1.0 appeared.

I tried running a test program that transferred a few bytes with spi1_d0 connected to spi_d1. The output of this program on my old BB White loaded with Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.11.22.img, using /dev/spidev2.0 was:
cmd: 0x02 0x12 0x34 0x56
rsp: 0x02 0x12 0x34 0x56

with Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.04.13.img on my BB Black it's always:
cmd: 0x02 0x12 0x34 0x56
rsp: 0x00 0x00 0x00 0x00

Looking at the signals with a logic analyser showed that the output (SPI1_D0) is correct.

I then moved the micro SD card from my BB Black to my BB White and discovered that it does the same thing, so the problem is not the Black but in the 2012.11.22 image (the only one that supports the Black). The problem seems to me be in the spidev driver or in the underlying hardware driver.

Any ideas?

bone-test.dts

spi-test.c

[randy rodes]

This an _ALMOST_ well known problem that many got bit by.

In reference manual, it states clearly that mux register can be
written _ONLY_ in Supervisor mode.
When in userspace you are in ARM user mode, and hence you can rightly
read the registers, but once you do a write, it will create some kind
of fault and probably your system should crash after a time.

Bottom line is - use kernel to program the mux registers.

3.8 kernel has a new framework for muxing via device tree blob.
Easiest could also be to just write these registers in any init
routine of a driver in kernel.

Best is to set mux as per the pinctrl 3.8 kernel method - but i have
not done much with it to help.

[randy rodes]

this was one reason to write my own mux legacy support for 3.8 kernel .

See the top most post on this thread:
https://groups.google.com/forum/?fromgroups=#!topic/beagleboard/GAJq481pQ-c

[Rafael Fiebig-Bindner]

I am not sure, if someone else will see this, so maybe I'll have to start a new Thread, but anyway I wanted to try it here first:
I have the same problem, like Alan had, I tryed setting the SCLK as an Input, but the problem is still there. i checked on an oscilloscope and every signal looks fine. Could someone please have a look at my .dts file, because I am quite new to DeviceTreeOverlay and not tottally sure, if there isn't a mistake in it.

 
/dts-v1/;
/plugin/;

/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";

    /* identification */
    part-number = "BB-SPI1-01";

    /* version */
    version = "00A0";

    /* state the resources this cape uses */
    exclusive-use =
        /* the pin header uses */
        "P9.31",
        "P9.29",
        "P9.30",
        "P9.28",
       // "P9.13",
       // "P9.12",
        "spi1";

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {

            pinctrl_spi1: pinctrl_spi1_pins {
                pinctrl-single,pins = <                                        
                    0x190 0x33    /* P9_31 = mcasp0_aclkx.spi1_sclk                 , INPUT_PULLUP | MODE3 */

                    0x194 0x33    /* P9_29 = mcasp0_fsx.spi1_d0                     , INPUT_PULLUP  | MODE3 */
                    0x198 0x13    /* P9_30 = mcasp0_axr0.spi1_d1                     , OUTPUT_PULLUP | MODE3 */
                    0x19c 0x13    /* P9_28 = mcasp0_ahclkr.spi1_cs0                 , OUTPUT_PULLUP | MODE3 */

                   
                  //  0x164 0x12  /* P9_42 = GPIO0_7 =  eCAP0_in_PWM0_out.gpio0[7] , OUTPUT_PULLUP | MODE2 */

                >;
            };
        };
    };

    fragment@1 {
        target = <&spi1>;
        __overlay__ {
            #address-cells     = <1>;
            #size-cells     = <0>;
            status            = "okay";
            pinctrl-names    = "default";

            pinctrl-0        = <&pinctrl_spi1>;    
            cs-gpios         = <&gpio4 17 0>, <&gpio1 7 0>;

            spi1_0{

                #address-cells       = <1>;
                #size-cells       = <0>;
                compatible           = "spidev";
                reg               = <0>;
                spi-max-frequency = <16000000>;

                spi-cpha;          
            };
            /*spi1_1{

                #address-cells       = <1>;
                #size-cells       = <0>;
                compatible           = "spidev";

                reg               = <1>;
                spi-max-frequency = <16000000>;
                // Mode 0 (CPOL = 0, CPHA = 0)
            };*/
        };
    };
};

PS: I use spidev, if that does somehow matter

[William Kentler]

Rafael,

I'm not sure if this'll help, but I got it working with this as my dts file (am335x-boneblack.dts)

/*

 * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/

 *

 * This program is free software; you can redistribute it and/or modify

 * it under the terms of the GNU General Public License version 2 as

 * published by the Free Software Foundation.

 */

/dts-v1/;

/include/ "am33xx.dtsi"

/include/ "am335x-bone-common.dtsi"

&am33xx_pinmux {

rstctl_pins: pinmux_rstctl_pins {

pinctrl-single,pins = <

/* eMMC_RSTn */

0x50 0x17 /* gpmc_a4.gpio1_20, OUTPUT | MODE7 | PULLUP */

>;

};

        bone_replicape_spi1_pins: pinmux_replicape_spi1_pins {

                pinctrl-single,pins = <

                    0x190 0x13    /* P9_31 = mcasp0_aclkx.spi1_sclk                 , OUTPUT_PULLUP | MODE3 */

                    0x194 0x33    /* P9_29 = mcasp0_fsx.spi1_d0                     , INPUT_PULLUP  | MODE3 */

                    0x198 0x13    /* P9_30 = mcasp0_axr0.spi1_d1                     , OUTPUT_PULLUP | MODE3 */

                    0x19c 0x13    /* P9_28 = mcasp0_ahclkr.spi1_cs0                 , OUTPUT_PULLUP | MODE3 */                    

                >;

        };

};

&ldo3_reg {

regulator-min-microvolt = <1800000>;

regulator-max-microvolt = <1800000>;

regulator-always-on;

};

&rstctl {

status = "okay";

compatible = "gpio-rctrl";

pinctrl-names = "default";

pinctrl-0 = <&rstctl_pins>;

#reset-cells = <2>;

gpios = <&gpio2 20 0x00>;

gpio-names = "eMMC_RSTn";

};

&mmc1 {

vmmc-supply = <&vmmcsd_fixed>;

};

&mmc2 {

vmmc-supply = <&vmmcsd_fixed>;

bus-width = <8>;

ti,non-removable;

status = "okay";

reset = <&rstctl 0 0>;

reset-names = "eMMC_RSTn-CONSUMER";

};

&cpu {

/*

* To consider voltage drop between PMIC and SoC,

* tolerance value is reduced to 2% from 4% and

* voltage value is increased as a precaution.

*/

operating-points = <

/* kHz    uV */

1000000 1350000

800000 1300000

600000  1112000

300000   969000

>;

};

&spi1 {

#address-cells = <1>;

        #size-cells = <0>;

        status            = "okay";

        pinctrl-names    = "default";

        pinctrl-0        = <&bone_replicape_spi1_pins>;    

        cs-gpios = <&gpio4 17 0>, <&gpio1 7 0>;

        cs0-device {

             #address-cells = <1>;

             #size-cells = <0>;

             compatible = "spidev";

             reg = <0>;

             spi-max-frequency = <16000000>;

         };

};

I compiled it using the following command:

dtc -O dtb -o am335x-boneblack.dtb -b 0 -@ am335x-boneblack.dts

and I've attached the three dependent  files.

Hope this helps.

William

[Rafael Fiebig-Bindner]

William,

when I try to compile your file I get the message, that "tps65217.dtsi" is missing. I searched my file system, but I couldn't find it anywhere.

Rafael

[Rafael Fiebig-Bindner]

PS: It is mentioned above, that the SCLK must be set as input. Is 0x33 the correct value for it?

[William Kentler]

ooops. Missed that one. Attached

[William Kentler]

I'm not sure about the input, but I know that the clock output is working, as I have successfully sent data to an external SPI slave. I'll put a wire between MSIO and MOSI when I get a chance and check that the input works correctly.

[Rafael Fiebig-Bindner]

Seems, like I didn't state my problem correctly: I have SPI1 working and I can send data without any problems, but when I try to receive data the input i get is always 0, although the signal at the wire is non-zero (same goes for SPI0).

[Rafael Fiebig-Bindner]

I just got a pretty obvious idea: Input is read at d0, right? I don't want to test it by wiring 2 outputs (d1, DAC-output) and end with one (or both) broken.

[drew...@gmail.com]

Apologies if this belongs in a separate thread, but I am also having trouble reading on SPI1. 

I am interfacing a BBB to two off-axis absolute angle encoders:
http://www.rls.si/en/aksim-off-axis-rotary-absolute-encoder--17584

I have the "Simple SPI slave" version that just sends a 16 bit position code over the SPI bus.  I have verified with a scope that CLK and CS signals from the BBB are valid, and that the sensor is transmitting the correct data on the MISO/SPI1_D0 pin. 

The behavior I get is that for each encoder value I get some sort of repeating pattern.  Each time I move the encoder what I read on the BBB switches to a new pattern.  Here are some example patterns:

0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
...

0x5555  0101010101010101
0x5555  0101010101010101
0x5555  0101010101010101
0x5555  0101010101010101
...

0x7FDF  0111111111011111
0xFF7F  1111111101111111
0xFDFF  1111110111111111
0xF7FD  1111011111111101
0xDFF5  1101111111110101
0x7FD7  0111111111010111
0xFF5D  1111111101011101
0xFD75  1111110101110101
0xF5D7  1111010111010111
0xD75D  1101011101011101
0x5D77  0101110101110111
0x75DF  0111010111011111
0xD77D  1101011101111101
0x5DF5  0101110111110101
0x77D5  0111011111010101
0xDF55  1101111101010101
0x7D57  0111110101010111
0xF55F  1111010101011111
0xD57F  1101010101111111
0x55FF  0101010111111111
0x57FF  0101011111111111
0x5FFD  0101111111111101
0x7FF7  0111111111110111
0xFFDF  1111111111011111
0xFF7D  1111111101111101
...

0xFFFD  1111111111111101
0xFFF7  1111111111110111
0xFFDF  1111111111011111
0xFF7F  1111111101111111
0xFDFF  1111110111111111
0xF7FF  1111011111111111
0xDFFF  1101111111111111
0x7FFF  0111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
0xFFFD  1111111111111101
0xFFF7  1111111111110111
0xFFDD  1111111111011101
0xFF77  1111111101110111
0xFDDF  1111110111011111
0xF77F  1111011101111111
0xDDFF  1101110111111111
0x77FF  0111011111111111
0xDFFF  1101111111111111
0x7FFF  0111111111111111
0xFFFF  1111111111111111
0xFFFF  1111111111111111
...

Another symptom is that I am getting a compiler warning that I don't understand on the line where I am setting the pointer to the read buffer:
spi_status.c:51:22: warning: assignment makes integer from pointer without a cast [enabled by default]

I find it absolutely baffling that the struct is expecting for the rx_buf field a 64 bit integer instead of a 32 bit pointer.

This is how I am setting up my ioctl:

#define RESPONSE_TYPE uint16_t
struct spi_ioc_transfer tr_azimuth;
memset(&tr_azimuth, 0, sizeof(tr_azimuth));
tr_azimuth.rx_buf = &rsp_azimuth;  // Throws warning
tr_azimuth.tx_buf = 0;  // NULL pointer is OK
tr_azimuth.len = sizeof(RESPONSE_TYPE); // in bytes
tr_azimuth.delay_usecs =       100;
tr_azimuth.speed_hz =        100000;
tr_azimuth.bits_per_word = sizeof(RESPONSE_TYPE)*8;
tr_azimuth.cs_change = 1;
int ret_azimuth = ioctl(fd_azimuth, SPI_IOC_MESSAGE(1), &tr_azimuth);

Relevant things I have tried:
* I tried both with and without "spi-cpha", although it should be on according to the data sheet; the slave changes MISO state on rising clock edge.
* I tried both with the CLK pin set as input/pullup and output/pullup
* I tried two beaglebones; same behavior
* A bunch of values for the struct for the ioctl call (In addition to the ones I think are correct)
* Making ioctl an array of structs of size 1 instead

Does anyone have any ideas?  I have tried everything I can think of, and may just start bit banging instead of using the linux API...

[Andrew Wagner]

Update, I tinkered a bit more.  I disconnected the line angle sensor, and just tried putting different signals into the MISO pin to try to debug my problem reading SPI1.

Attaching MISO to GND -> 0x0000 as expected
Attaching MISO to 3.3V -> 0xFFFF as expected
Leaving MISO free -> 0xFFFF as expected, since it is configured with a pullup
Attaching MISO to CS -> 0x5555  NOT expected!  This should be 0x0000!

Any idea what could cause this?  Maybe the input part of the SPI hardware is operating at a different clock rate than the output part? 

Just to be safe I changed the max clock rates for SPI in my .dts file to be consistent with what I am setting in the ioctl call.  Also, I am still getting the same behaviour with a read() as with an ioctl() calll. 

[Rafael Fiebig-Bindner]

Its been a while, but I think I should post my solution to my problem (3 posts up):

You not only have to set the clock as Input, but also deactivate Pullup/-down

 

[ara...@gmail.com]

I am new to the Beaglebone Black, and am not having any luck with getting SPI working.

I have used SPI before, so I understand how it should work, but the existing documentation for getting it working with device tree on BBB is not working for me.

(When I use a jumper between input and output and run spidev_test I see all 00s instead of desired pattern.)

Is there a single, step by step description somewhere that is based on a current software image that can be downloaded?

I.E. I am looking for something I can download a new image to flash to my BBB, and follow step by step directions to get SPI0 and SPI1 working for read and writes.

Thanks,

-Arlen

[Andrew Wagner]

Hi Arlen,

The coverage for setup up a device overlay tree here is pretty good:

http://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/overview

With that and glancing at some other samples, we were able to get
writing to work. We did not get reading working in time for our
deadline, and resorted to bitbanging from userspace code. I have not
had a chance to try Rafael's advice (clock as input, deactivate pull
up / pull down).

Cheers,
Andrew

> --
> For more options, visit http://beagleboard.org/discuss
> ---

> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/NADsTC5Ro-I/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Rafael Fiebig-Bindner]

Just for clearence: Deactivate Pullup/-down is only needed at clock. 

[ara...@gmail.com]

I got spidev working on my BBB, I can do simultaneous reads and writes via c.

For testing, I would like to use one BBB to be a test data source via SPI, with another consuming this data stream.

Currently, I am unable to do this as with my configuration the BBB is always providing clock, never consuming it.

This seem strange to me, since it is configured as an input.  To check that the clock pin is actually being driven I placed a 10k resistor to ground on the clock line, and did a series of reads from the SPI device.

The clock line was driven.

Is there a way to configure the BBB SPI to behave as a slave, where it expects to be receiving a clock from an external device?

Thanks,

-Arlen

[lper...@fiu.edu]

Rafael, Would you mind posting you DTS file??? I have been trying to make the SPI clocl work, but I haven't had any luck!

Thank you, 

Laura

[mgla...@gmail.com]

Alan:

Not sure if you got it to work, but the following worked for me.
I am using a BBB with
Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l GNU/Linux
I compiled your spi-test.c program and connected d0 to d1 and it ran perfectly.

root@beaglebone:~# ./BB-SPiTest

cmd: 0x02 0x12 0x34 0x56
rsp: 0x02 0x12 0x34 0x56

The main difference is that I used SPI0 instead of SPI1. I used the device tree overlay shown here:
http://elinux.org/BeagleBone_Black_Enable_SPIDEV
This web page shows how to use SPI1 first, and towards the end of the page shows the dts file for SPI0 (the one I tried). My guess is that you may still having some problems with the HDMI using those pins.

Martin

[samr...@gmail.com]

Have you had any luck getting the spi0 clock working on the BBB (rev A6) using Ubuntu (3.8.13-bone30) ? I've done all the following

1) Added "capemgr.enable_partno=BB-SPIDEV0" to uEnv.txt in boot/uboot . This is the right uEnv.txt file as its in the FAT boot portion.

2) checking with "cat /sys/devices/bone_capemgr.9/slots"  I see the SPIDEV override

3) checking "ls -al /dev/spi*" I get the expected "/dev/spidev1.0 and /dev/spidev1.0" files

4) I added Adafruit_BB library and the CS pin (P9_17) can be toggled from here

5) Shorting pins 21 and 18 I can see data transfer so internally the spi clock works as expected.

However connected SPI_CLK(P9_22) to a logic analyzer I see no clock signal! I am certain the logic analyzer is ok since with hdmi enabled I can see clock signals on pins 25 and 31. I don't know why I am not getting a clock signal for SPI0. I just get the clock 'low'. The same thing happens when I disable hdmi and enable spidev1 instead; I get no clock signal on SPI1 clock  (pin 31). 

Any suggestions on what I may be missing? 

[Andrew Wagner]

Hello Sam,

We never did get SPI working though the device file in Angstrom and ended up just bitbanging the same pins as GPIO.  Our bitbanged clock signal is wack, but the spi slave we're reading from doesn't seem to mind.  Unless someone has submitted some changes to the spi driver in between what I was using and the most recent kernel, I'd recommend you just try bitbanging.

You might try changing the direction of the clock pin to be the opposite of what it should; I think we were at least able to get a clock out, but couldn't read the data correctly.

I recently spent some time trying out bare metal, but I didn't even manage to get an LED to blink with TI starterware (BBB is not officially supported yet).  

Just today I was able to boot into the most recent ubuntu 12.04 image from armhf; I had some stupid hardware problems where the hdmi plug was too big and I could either connect to a monitor or a keyboard but not both :)  I will probably not want to mess with the BBB we're bitbanging SPI on again, but if I do, I'll let you know.

Cheers,

Andrew

--

[Ventura]

Your are totally right but I didn't find any reference explaining that.
In the manual from TI,

AM335x ARM® Cortex™-A8 Microprocessors(MPUs)
Technical Reference Manual - SPRUH73H

 Session 24.2.3: McSPI pin list there is a description about SPIx_SCLK and you read:

SPI serial clock (output when master, input when slave)

There is also one note at the bottom saying:

(1)This output signal is also used as a re-timing input. The associated CONF_<module>_<pin>_RXACTIVE bit for the output clock
must be set to 1 to enable the clock input back to the module.

Thank you for the tip.
 

 

On Tuesday, May 7, 2013 10:51:59 AM UTC-5, Wally Bkg wrote:

Its a quirk of the SPI hardware as far as I can tell, even on the original Beagleboard the SPI_CLK pinmux has to be set as an input.

I agree it doesn't seem "logical".


On Tuesday, May 7, 2013 10:29:07 AM UTC-5, ky...@cranehome.info wrote:

Isn't that the serial clock?  Isn't it generated by the host and thus an output?  Or is it generated by some hardware and taking it over as an output is clobbering that?

On Tuesday, May 7, 2013 8:27:01 AM UTC-5, Alan Backlund wrote:

Changing SCLK to an input works.

Thank You

[gangadha...@gmail.com]

Hi Alan,
Thanks for your post and spi test code. This helped me and was able to fix SPI read issue.

Regards,
Gangadhar

On Monday, May 6, 2013 at 7:10:38 PM UTC+5:30, Alan Backlund wrote:

I have been trying to get SPI1 working on my new BB-Black, the output works but the input always reads 0.

The first thing I discovered is that SPI1 is used by the HDMI interface. I created a modified am335x-bone-common.dtsi with the hdmi sections removed. Putting the new am335x-boneblack.dtb into /boot and rebooting got rid of the SPI1 signals. I then loaded a new device tree that enables spidev (See bone-test.dts below). /dev/spidev1.0 appeared.

I tried running a test program that transferred a few bytes with spi1_d0 connected to spi_d1. The output of this program on my old BB White loaded with Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.11.22.img, using /dev/spidev2.0 was:
cmd: 0x02 0x12 0x34 0x56
rsp: 0x02 0x12 0x34 0x56

with Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.04.13.img on my BB Black it's always:
cmd: 0x02 0x12 0x34 0x56
rsp: 0x00 0x00 0x00 0x00

Looking at the signals with a logic analyser showed that the output (SPI1_D0) is correct.

I then moved the micro SD card from my BB Black to my BB White and discovered that it does the same thing, so the problem is not the Black but in the 2012.11.22 image (the only one that supports the Black). The problem seems to me be in the spidev driver or in the underlying hardware driver.

Any ideas?

bone-test.dts

/*
* Copyright (C) 2013 Alan Backlund

*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;

/plugin/;

/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";

    part-number = "BB-BONE-TEST-01";
    version = "00A0";

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {

            bone_replicape_spi1_pins: pinmux_replicape_spi1_pins {
                pinctrl-single,pins = <
                    0x190 0x13    /* P9_31 = mcasp0_aclkx.spi1_sclk                 , OUTPUT_PULLUP | MODE3 */
                    0x194 0x33    /* P9_29 = mcasp0_fsx.spi1_d0                     , INPUT_PULLUP  | MODE3 */
                    0x198 0x13    /* P9_30 = mcasp0_axr0.spi1_d1                     , OUTPUT_PULLUP | MODE3 */
                    0x19c 0x13    /* P9_28 = mcasp0_ahclkr.spi1_cs0                 , OUTPUT_PULLUP | MODE3 */                   
                >;
            };
        };

    };

    fragment@1 {
        target = <&spi1>;
        __overlay__ {

            #address-cells = <1>;
            #size-cells = <0>;
            status            = "okay";
            pinctrl-names    = "default";
            pinctrl-0        = <&bone_replicape_spi1_pins>;   
            cs-gpios = <&gpio4 17 0>, <&gpio1 7 0>;

            cs0-device {
                #address-cells = <1>;
                #size-cells = <0>;
                compatible = "spidev";
                reg = <0>;
                spi-max-frequency = <16000000>;
            };
        };

    };

};

spi-test.c

/*
* Copyright (C) 2013 Alan Backlund

*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/

[waplu...@gmail.com]

Thanks - you saved my day!  I just ran into the same quirk.  Truly bizzare that the SPI_CLK pinmux has to be set as an input in master mode where the pin is clearly an output.

On Tuesday, May 7, 2013 at 10:21:11 AM UTC-6, ky...@cranehome.info wrote:

Ok at least I'm not that stupid then. ;)

[Bruce Snyder]

It's probably for clock-stretching.  Both pins clock and data need to go both ways.

[Adrian Godwin]

I2C uses clock stretching but I'm not aware of any SPI interfaces that do it. However, it may be that the hardware is shared.

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/6138aa63-d406-4679-a0ab-8bf32189a8d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bruce Snyder]

OK sorry I thought you were referring to config pin on I2C.

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/NADsTC5Ro-I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALiMYrv8pfo4odn8WEJCyQLs9g6ZPZZj8y-J0aJ28fQyaGbOmw%40mail.gmail.com.